Draw the actual payment route before testing
Identify the gateway, supported payment methods and whether the customer is redirected, uses embedded fields or interacts with a different provider-supported design. Record the systems that receive payment references and the component responsible for changing the order. Include wallets, subscriptions and delayed methods only where they actually apply.
Separate what the customer sees from what the server knows. A browser return can show a page while a payment remains pending or a server notification fails. Conversely, a payment can complete at the provider while a local error prevents the expected order display. Begin with a map of those independent observations rather than assuming one screen represents every system.
Assign the store developer, provider-account owner and business approver. Agree on what success means for each method and which outcomes require manual review. This is a controlled acceptance plan, not authorization to probe a gateway or inspect another merchant’s payments.
Review browser controls and merchant responsibilities in context
Check the expected destination, secure transport and code loaded on the relevant checkout pages. HTTPS protects its transport connection; it does not establish that every script is appropriate or that server-side payment confirmation is implemented correctly. Review changes to tags, themes and plugins that affect this journey.
PCI SSC FAQ 1588 addresses a particular SAQ A script eligibility condition for embedded payment pages and distinguishes that condition from redirect arrangements. It does not give every merchant the same assessment scope. Confirm the actual arrangement and accepted validation with the processor or acquirer; do not treat a hosted checkout, this checklist or a website scan as a certificate.
Keep evidence free of real payment secrets and card data. A diagram of the route, configuration references and invented transaction markers is usually more useful for planning than a screenshot of a live customer payment. Where detailed payment investigation is required, use the provider’s approved support and evidence channels.
Isolate payment, messages and fulfillment before any test
Use a protected nonproduction environment and the payment provider’s supported test mode. Confirm the credentials and destination account, not just a label in the website dashboard. Review email delivery, stock integrations, accounting, fulfillment, scheduled jobs and webhooks so a fictional order cannot produce an unintended business action.
WooCommerce’s test-order documentation notes that test orders can trigger normal order behavior and that connected extensions may not distinguish them from real orders. A copied production database and live keys can therefore make an apparently separate staging site unsafe for testing.
Prepare the test identities, permitted outcomes and cleanup responsibility. Do not enter real card information into an improvised test or make a small live charge simply to check whether the button works. Any exceptional live verification needs its own authorized provider-specific plan outside the default exercise described here.
Verify outcomes and side effects separately
Agree on the expected state for each supported outcome and which source confirms it. Include the customer view, provider result, server processing, order state and downstream effects. A generic checklist cannot determine the exact status names used by every gateway or extension.
Use an acceptance record like this original example. The store developer and provider should adapt the expectations to the real payment method. Do not force an immediate “paid” outcome for a method whose documented process is asynchronous or requires a later step.
| Controlled outcome | Evidence to compare | Side effect to check |
|---|---|---|
| Supported test success | Provider reference and authenticated server handling | Expected order transition without duplicate fulfillment |
| Declined or failed test | Provider result and store error handling | No invented success or unintended stock/dispatch action |
| Customer cancellation | Agreed provider and store states | No assumption that a browser exit reverses every event |
| Pending or delayed result | Documented method behavior and later confirmation | Appropriate hold and owned follow-up |
| Repeated notification | Same business event recognized under supported handling | No repeated charge, message or fulfillment effect |
| Interrupted integration | Target-system evidence and recovery procedure | Clear exception rather than silent success |
Verify server messages and duplicates without trusting a signature alone
The receiving integration should use the provider’s documented authentication or signature verification and relate the event to the intended account, transaction and order. A verified message still needs appropriate business checks. Repeated or delayed events should not cause a second action merely because they arrive again.
WooCommerce’s webhook documentation describes destinations, a signing secret and delivery records. Delivery evidence helps trace a handoff, but a response status does not establish that the receiving system applied the intended business result. Check both systems and their agreed duplicate-event behavior.
Record gaps and keep payment review connected to changes
Save the tested version, gateway mode, synthetic event references, expected results, observations and exclusions. Distinguish security boundaries from ordinary compatibility or process defects. Both may matter, but a delayed status update is not automatically evidence of compromise.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide. Our practical Israeli website and digital-infrastructure knowledge helps connect checkout, accounts and integrations into an agreed review. Start with the gateway name, website route and symptom. Keep customer records, payment secrets and card details out of the initial enquiry.
Recheck after a relevant gateway, theme, checkout, script or integration change. Decide who owns unresolved results and the release decision. The outcome is a bounded acceptance record, not a guarantee that every payment method or future change has been certified secure.
