Cybersource on WooCommerce should be assessed through the merchant account, the installed extension and a documented test checkout. Start by confirming the required account features and environment, then compare the transaction result with the WooCommerce order. Keep authorisation, capture and customer-facing messages clear so the team can explain what the test actually establishes.
A gateway appearing in checkout is only one part of the review. The merchant needs the appropriate account configuration, the extension needs the corresponding settings and the store needs an understandable order outcome. Record each layer separately before deciding that the proposed payment route is ready for an operational acceptance exercise.
The original account-to-order worksheet below uses designated sandbox transactions and fictional customer details. Product facts come from WooCommerce’s Cybersource extension and core testing guidance, retrieved on 24 October 2026. For the wider payment decision, see online payments and online stores.
Which account capabilities must be confirmed?
The WooCommerce Cybersource extension requires an active gateway account with JSON REST API enabled. The extension guide describes this prerequisite. Record the merchant’s confirmed account configuration through its authorised private records before treating the extension’s feature list as evidence of what the account can use.
The extension requires an SSL certificate for the store. Cybersource connection settings use a Merchant ID, API key and shared secret. Identify the person authorised to maintain those settings and the private storage route used by the project. Ordinary acceptance material can identify the configuration owner without containing the secret values.
Cybersource eCheck support depends on the merchant account’s processor configuration. Include only the payment methods actually required by the brief, and retain account-specific confirmation where relevant. The documentation supplies product prerequisites; it does not establish eligibility or local availability for a particular applicant.
Flex Microform requires tokenisation to be enabled in the Cybersource merchant account. The extension uses the Payments REST API with Flex MicroForm support, not the Secure Acceptance Hosted Checkout API. Extension FAQ. For a reseller-managed account, have the account contact confirm its actual API configuration. WooCommerce identifies an unsupported store currency as a cause of INVALID_REQUEST: Declined. Confirm support for the store’s actual currency with the account contact before the sandbox exercise.
Visa Acceptance requires Client Services confirmation of Live status before its production account setup procedure. A DevCenter account cannot be taken live; Visa Acceptance directs its owner to Sales to set up a live account. Production setup. In your acceptance checklist, request evidence for the live merchant account, the intended services and their enablement. Record the relevant sign-up or setup wizard stage and any unresolved step separately; a sign-up identifier alone is not the merchant-account acceptance decision. Keep production confirmation separate from sandbox test observations.
What does the transaction setting mean?
The extension’s Charge setting captures payments automatically. Authorization mode supports later manual capture, subject to the automatic-capture options for virtual-only and paid orders. In Authorization mode, Charge Virtual-Only Orders can automatically capture orders containing only virtual products. In Authorization mode, Capture Paid Orders can automatically capture charges when orders move to a paid status. Capture settings. Inspect both actual settings and the sample order’s product types before defining the expected capture event. Assign an operator only where the selected route needs a later manual action.
Displayed card logos do not determine which cards the merchant account accepts. Treat the visual presentation as a separate review from account capability. The shopper should see a clear payment option, while the operational evidence should identify the actual methods confirmed for the merchant account.
The extension switches between Test and Production credentials through its Environment setting. Use the documented test arrangement for the exercise and record the selected environment. Keep the expected account and transaction references on the worksheet so a reviewer can connect the store result to the corresponding test transaction.
| Review layer | Proposed evidence | Question to resolve |
|---|---|---|
| Merchant account | Live-account confirmation, REST/Flex enablement and currency | Are the account and intended services confirmed for this store? |
| Connection | Correct environment and private configuration owner | Which account receives the test? |
| Transaction mode | Charge or Authorization, automatic-capture options and product types | Which exact event should capture this order? |
| Checkout | Actual shopper-facing option and response | Is the next action understandable? |
| Order | Status, notes and transaction reference | Does the store record match the test result? |
| Exception | Relevant evidence and responsible role | Who investigates a declined or uncertain result? |
The table is an original verification brief. Populate actual observations only when the approved sandbox exercise is performed.
How should the test environment be prepared?
WooCommerce says test orders can trigger emails and enter store analytics. WooCommerce also says test orders have no special visual status distinguishing them from real orders. Its testing-orders guide makes connected processes part of the preparation checklist.
Use a separate staging store and designated test recipients. Identify the fulfilment, accounting and communication connections that could act on a sample order, then arrange the exercise so those effects remain controlled. Retain the test fixture and configuration with the observations rather than relying on a colleague remembering which orders were fictional.
WooCommerce recommends checking each integration’s treatment of test scenarios. The gateway’s sandbox result and the store’s downstream behaviour should therefore be reviewed together. Ask the responsible owner which actions should occur during the exercise and how they will recognise the sample transaction.
For account authentication or transaction cases, follow the current official test instructions linked by the extension guide. Keep test inputs distinguishable from real payment credentials and avoid copying sensitive account material into the ordinary worksheet. The useful acceptance evidence is the test case, environment, reference and observed result.
Include the expected customer-facing wording in the acceptance sheet. Ask a reviewer to distinguish a declined attempt, a pending investigation and an established successful test from the messages alone. Retain any unclear wording as a specific checkout requirement, with the underlying account and order evidence attached privately.
Original merchant-to-order acceptance exercise
Prepare a fictional order with a designated test customer in staging. Write the expected gateway environment, transaction mode and order result before starting. Identify the merchant owner, store operator and person responsible for investigating discrepancies. Record the relevant extension and checkout versions.
Begin with the documented successful sandbox case. Inspect the shopper’s response, WooCommerce order and corresponding gateway test record. Retain the identifiers that connect them. Ask the store operator to explain what the result means under the chosen Charge or Authorization mode and what action remains, if any.
If Authorization is the intended mode, record Charge Virtual-Only Orders and Capture Paid Orders alongside the sample product types. Rehearse the capture event expected under those actual settings: the relevant automatic trigger, or a later manual capture with its named operator. Compare the resulting order and gateway evidence with the original authorisation record.
Next, use the documented declined-transaction case appropriate to the account and integration. Record the message shown to the shopper and the evidence available to the operator. Check that the next action is understandable without revealing private diagnostics to the customer.
Then assess an uncertain-result scenario through an agreed safe test fixture. Ask the operator which evidence they would inspect before repeating a transaction or changing an order state. Keep the investigation route with the acceptance record so the team can distinguish a missing response from an established payment outcome.
Finish by reviewing the order’s effect on the staged downstream processes. The complete sheet should connect account capability, environment, transaction evidence and operational ownership. For the underlying platform, see WordPress. To discuss the merchant requirements and remaining checkout questions, get started with the worksheet.
Include a cancellation at the payment handover in the proposed checkout exercise. Record the order identifier, the visible customer message and the administrator view, then reconcile the expected status against the documented integration behaviour.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.