Payment Launch Checklist: 16 Acceptance Tests

Prepare before testing

Use the agreed test environment and applicable documentation. If a check requires a real transaction, arrange it with the person responsible for the connection beforehand, including the amount, refund and accounting treatment. A row in this checklist does not mean the corresponding feature is enabled for a particular merchant.

Record the integration version, available methods, currency, permitted statuses and how results will be verified. Prepare a test order, a place to retain evidence and responsible contacts. Every result should be traceable to an order and a linked payment attempt.

Define what fulfilment means for the business: dispatching goods, activating access, delivering a digital item or handing an order to a location employee. The team can then verify how many times that action occurred.

A matrix of 16 scenarios

Add columns for “Actual result”, “Evidence”, “Owner” and “Resolution”. Mark a case as passed only after checking both the interface and the server-side record.

No.	Scenario	Expected result	Evidence to retain
1	Normal successful payment	The confirmed payment is linked to the correct order and the purchase is fulfilled once	Order and payment identifiers, final status and fulfilment record
2	The payment button is pressed twice	Repeated action does not cause duplicate fulfilment; attempt creation follows the documentation	Number of attempts created and number of order fulfilments
3	A new attempt follows a completed unsuccessful attempt	The previous attempt remains in the history; the new one links correctly to the same order	Both attempt identifiers and their order relationship
4	The customer cancels confirmation	Opening the result page alone does not mark the order as paid	Attempt state, order state and customer message
5	The attempt expires	The result is clear and any replacement follows the integration's rules	Expiry, verified status and the result of reopening the page
6	The tab is closed after handover to payment	Order updates do not depend on the customer's browser staying open	Server notification or status check and the order outcome without the client tab
7	The customer returns before the notification	The interface shows a waiting state and then the current result; no premature fulfilment occurs	Sequence of page and order states
8	The same notification is delivered again	The event follows the integration's processing rules; goods, access and balances do not change again	Repeated events and a single fulfilment record
9	Notifications arrive out of order	The system follows permitted transitions and does not replace a current state with stale information	Event receipt times and state transition history
10	The notification handler is temporarily unavailable	The outcome is recovered through an agreed mechanism: redelivery, a status query or reconciliation	Failure cause, recovery action and confirmed outcome
11	The browser submits a changed amount	The server preserves the agreed order price and rejects incorrect data	Expected amount, a request record without secrets and the final record
12	A full refund and an available partial refund	The refund links to the original transaction, has a separate outcome and stays within the permitted amount	Original payment and refund identifiers, amounts and statuses
13	Reconciliation for a chosen period	Successful payments match by ID and amount; refunds and fees are recorded separately	Register, order list and explained discrepancies
14	Payment on different devices	The actually supported phone, desktop and embedded browser complete the full journey	Device, browser, launch context and outcome for each run
15	Support investigates an enquiry	An employee finds the original attempt from the order and explains the next step without payment secrets	Practice enquiry, matching records and assigned owner
16	Access and measurement review	Secrets are absent from the public interface and open logs; orders are counted separately from attempts	Key placement review and an analytics event description

The connected payment infrastructure defines technical status names, redelivery rules and refund availability. Do not transfer the behaviour of one API to another without checking the documentation.

Retain useful evidence

An investigation usually needs identifiers, times and the expected and actual outcomes. A screenshot helps show the interface but does not replace a server-side result. Remove secrets and unnecessary personal information from material shared in a work chat or development ticket.

Avoid a bare “does not work” result. A useful record explains the sequence: which order was created, what action was taken, which event arrived, what changed in the order and how the result differed from the expectation.

For example, a practice case where the customer returns before the notification should verify two things separately: a waiting state appears first, and the correct outcome appears after confirmation. A polished success page shown before confirmation does not pass that test.

Assign acceptance responsibilities

Engineering checks attempt creation, statuses, notification processing and technical records. The business owner confirms correct fulfilment and understandable messages. Finance reconciles amounts, fees and refunds. Support verifies order lookup and escalation.

For a physical location, include a shift employee who needs to distinguish “waiting for confirmation” from “paid”. For a digital service, count access activations separately. These checks reveal issues that a single API response review can miss.

Set launch criteria

Resolve issues that could cause an incorrect amount, duplicate fulfilment, loss of a confirmed payment or an enquiry that cannot be investigated. An unknown outcome should remain unknown until checked; it should not automatically become success or a definitive rejection.

Record unresolved limitations, an owner and a monitoring method for the launch period. Compare conversion over a defined period and a consistent group of operations. Do not silently divide successful orders by a count that includes every repeated attempt.

Repeat affected scenarios after a material change to the integration, interface or fulfilment rules. Retesting should target the risk introduced by that change rather than become an endless repetition of identical checks.

Next steps with WhiteCapital Tech

Use the matrix when discussing payment API integration or website payment acceptance. There are separate guides for mobile SBP checkout and QR payments at a physical location.

WhiteCapital Tech assesses connections after project review. Methods, environments, refunds, limits and commercial conditions are agreed individually. This test list does not claim that unconnected features are available or replace acceptance of an individual project.

Questions and answers

Is one successful test payment enough?

It confirms one scenario. Launch testing should also cover errors, waiting states, repeated actions, fulfilment and reconciliation within the available connection.

Can the matrix be applied to every API unchanged?

Use it as a starting point. Check status names, permitted transitions, repeated notifications and refunds against the individual API documentation.

Does a screenshot of the success page prove the test passed?

Also verify the server-side outcome, the relationship to the correct order and the number of fulfilments. A screenshot alone does not establish those facts.

What if a listed feature is unavailable?

Mark the case “not applicable” and record why. Do not show customers or promise the business a feature that has not been approved and connected.

Sources and scope

This matrix is an original editorial tool for integration acceptance. Public documentation helps define what to test, but each case's expected statuses and limits must be confirmed in the documentation and agreement for the particular connection. This guide contains no results of real testing, promises of conversion growth or universal list of enabled features.

This is practical guidance. Available methods, equipment integration, limits, fees and settlement terms depend on project approval and the agreed documentation.