What must be ready before TEST access
A bank or provider checks not only integration code, but also website readiness for accepting payments.
Before TEST access, the website should be ready technically and content-wise: HTTPS, stable domain, contact pages, payment terms, refund rules and delivery or service terms. This matters because the provider evaluates where the customer enters payment details and which rules are visible before payment.
AEB publicly describes vPOS website requirements and TEST/REAL stages. Even when another bank uses a different checklist, closing this minimum first helps avoid delays after application.
- working HTTPS and correct domain;
- contacts, legal details and refund rules;
- clear product or service descriptions;
- success, fail and pending pages;
- responsible developer for TEST credentials.
Which test cases are mandatory
One successful test payment does not prove that the payment flow is production-ready.
A minimum test matrix includes successful payment, refusal, pending, closed tab, repeated success URL, repeated webhook delivery, a second attempt for the same order and CRM/ERP status verification.
If the project includes fiscalization, test the receipt queue separately: receipt after confirmed payment, data error, retry, manual review and receipt linkage to payment id. If refunds exist, test full and partial refund.
- create payment session with fixed amount;
- verify final status server-side;
- handle duplicate webhook idempotently;
- send normalized statuses to CRM/ERP;
- show correlation id to support.
When it is safe to switch to REAL
REAL launch is safer when the team knows both happy path and exception handling rules.
Switch to REAL after critical scenarios pass, logs are available, webhook endpoint is stable and support knows what to do with pending, failed, refund and mismatch cases.
Production should start gradually: one channel, one payment method, limited product or invoice scope, daily reconciliation and a fast communication channel between manager, developer and payment owner.
- test case checklist is complete;
- rollback or temporary payment disable path exists;
- support instructions are ready;
- daily reconciliation is enabled for first days;
- errors go to a log, not only server console.
FAQ
Can a project switch to REAL after one successful test payment?
No. Test refusal, pending, repeated webhook, closed tab, retry, CRM/ERP statuses and support handling for disputed cases.
What if the bank asks to improve the website before connection?
Treat it as part of the launch checklist: HTTPS, contacts, payment and refund terms, product/service descriptions and correct payment result pages.
Should refunds be tested before launch?
Yes, if refunds exist in the process. Check linkage to original payment id, CRM/ERP status and fiscal workflow.
Sources
- Armeconombank - VPOSOfficial page with website requirements, TEST/REAL stages and vPOS conditions.
- Evocabank - V-POS terminalOfficial V-POS description for websites and mobile applications with 3D Secure.
- Stripe Documentation - Webhook signatures and deliveryOfficial guidance on signature verification, repeated delivery and webhook behavior.
