A payment integration should let you verify the payment request, provider result and final order state. Displaying a payment screen does not prove those three points are connected.
Prepare the test environment
Use the credentials, endpoints and test data documented for your integration version. Keep them separate from production and identify each fictional order. Do not use real buyers’ cards, names or records to demonstrate the flow.
A minimum test matrix
| Scenario | Expected evidence |
|---|---|
| Successful payment | Correct amount and currency; one sale updated |
| Decline | Order remains unpaid with an accurate message |
| Abandonment | Attempt remains traceable without inventing its financial outcome |
| Timeout | Result resolved before another charge is requested |
| Late confirmation | The same operation is updated |
| Repeated notification | No additional charge or duplicate fulfilment |
| Supported test refund | Movement linked to the original payment |
The table defines expected outcomes. Adapt the execution steps to the contract and environment of your integration.
Browser return versus server notification
Customers can close the tab or lose connectivity. The server should validate the outcome through a trusted integration channel. A return URL or browser-controlled parameter should not be enough to mark a sale paid.
Also check that amount, currency and identifier match the intended sale. A valid signature does not replace the other business checks.
What should you record?
Record the scenario, version, fictional identifier, expected result and observed result. Include what changed in the store. Do not copy secrets or complete payment details into the test record.
After a fix, rerun the failed case and verify the affected journey. A local test does not demonstrate that every real sale will succeed.
Start with AndorPay’s testing guide, in Spanish. If you are still choosing an integration approach, read SDK or direct API.