Testing with the sandbox, and a go-live checklist

The worst way to find out that your checkout has a bug is with a customer's money in it. Paynet has a full sandbox precisely so that the first real payment you take is boring: you already know exactly what happens on success, on decline, on timeout and on a refund, because you have watched each of them happen.

This post covers what the sandbox gives you, how to drive it, and then the checklist that decides whether you are actually ready to take live payments in Armenia.

Test keys and live keys

API keys carry an environment. A test key starts with sk_test_ and turns every payment made with it into a sandbox payment. A live key starts with sk_live_ and takes real money.

Every new Paynet account starts with a key named Default. It is a test key, so it creates sandbox payments only. You can start integrating with it immediately, before any verification and before your bank paperwork is done. Create a live key when you are ready for real payments.

Keys are also scoped. When you create one you pick its access level:

• Full access creates, reads and refunds payments, and can buy units. Keep it on your own server.
• Payments only creates and reads payments and payment links, but cannot refund or spend your balance. It is the right key to hand to a storefront or a contractor, and it returns 403 insufficient_scope on the calls it is not allowed to make.

Keys are SHA-256 hashed at rest and the raw value is shown once, at creation. Copy it then and store it in an environment variable. If you lose it, revoke the key and make a new one.

One more scoping detail that saves confusion: a test key lists only sandbox payments and a live key only live ones. Looking up a live payment with a test key returns a 404, not an error explaining the mismatch. If a payment you can see in the dashboard is invisible to your code, check which key your code is using.

Two ways into the sandbox

There are two doors, and they lead to the same room.

A test API key. Use sk_test_ and every payment it creates is a sandbox payment.

The Sandbox provider. Install it from Providers in your dashboard and send "processor": "sandbox". This one also works inside the CMS plugins, which matters: it is how you test a real storefront end to end, with a real cart and a real order, without writing any code.

Either way, no bank is contacted, no money moves, and nothing is billed or counted. Test payments appear under the Test tab in your dashboard, so they never contaminate your revenue figures.

The test cards

On the test checkout the card number decides the outcome:

Card number	Result
4111 1111 1111 1111	Approved
4000 0000 0000 0002	Declined by issuer
4000 0000 0000 0069	Insufficient funds
4000 0000 0000 0119	Processor timeout
4000 0000 0000 0101	3-D Secure failed
4000 0000 0000 0127	Amount limit exceeded
4000 0000 0000 0200	Duplicate transaction
4000 0000 0000 0259	Transaction expired
4000 0000 0000 0309	Processor unavailable
4000 0000 0000 0341	General failure

Any other sixteen digit number is approved. Expiry, CVV and cardholder name are not checked, so enter anything.

A test plan worth running

Running only the approved card proves almost nothing. The failures are where shops break. A reasonable minimum:

1. Approved. The order becomes paid, the customer sees confirmation, stock moves, the email goes out.
2. Declined by issuer. The order does not become paid, the customer can try again, and no stock is consumed.
3. Processor timeout. Your code does not hang or double charge. This is the case that tells you whether your timeouts and retries are sane.
4. Abandoned payment. Create a payment and simply do not pay it. It expires after 20 minutes and fires a webhook with expired. Confirm your shop cancels or releases the order.
5. Refund. Refund a completed sandbox payment, full and partial, and confirm your records match. Send an Idempotency-Key so a retry after a timeout returns the same refund instead of making a second one.
6. Webhook replay. Deliver the same event twice and confirm your handler ignores the duplicate on delivery_id.

Test payments fire webhooks with livemode: false, so the whole notification path is provable before launch. Details of every field are in the API reference.

The go-live checklist

Sandbox green does not mean live. Five things stand between you and a real payment.

1. A verified domain

Buyers can only pay on a domain you have verified, and return_url, cancel_url and callback_url all have to point at one. Add the domain in the dashboard and prove you control it: a DNS TXT record, a plain text file at your site root, or an ownership acknowledgement. If you connected a store with a plugin, the Connect flow verified the domain for you.

Two practical notes. localhost cannot be verified, so verify your staging hostname if you want to test from it. And confirming ownership means accepting responsibility for the payments that run through that domain, including chargeback liability, so verify only domains that are genuinely yours.

2. A verified business

Live payments open after business verification. You submit your legal business name, TIN, legal form, registered address and contact phone, plus the documents that match your legal form: the state registration certificate, the TIN certificate and the ID of the authorised person. Only the account owner can submit them.

Reviews normally take one to two business days, and the decision arrives by email and in the dashboard. Until then everything works in test mode, with unlimited free test payments, so this is a good thing to submit early and build against while it is in review.

If a call returns VERIFICATION_REQUIRED, this is what it is asking for.

3. A real provider, connected and turned on

Paynet is a gateway, not an acquirer. You bring your own accounts: an ARCA card gateway from your bank, an Idram merchant account, a Telcell merchant account. Add the credentials in Providers, then turn the provider on for the specific domain. A provider that is saved but not activated for any verified domain means buyers still cannot pay, which is the most common reason a launch quietly fails.

Use Test credentials in Providers to have Paynet ask the provider whether your stored credentials still work, rather than discovering it with a customer.

Some providers have their own prerequisites on their side. If your bank requires the connecting server's IP address to be whitelisted, Paynet shows you the address to send them, and payments through that provider fail until they have done it.

4. A working webhook

Set a webhook URL for the domain, or send callback_url when you create the payment. Then press Send test webhook in the domain's webhook settings and confirm the delivery log shows a success.

Your handler should verify the X-Paynet-Signature HMAC over the raw body, answer 200 within 10 seconds, dedupe on delivery_id, and then read the payment back with the order status endpoint before marking anything paid. Failed deliveries are retried after 1, 5 and 30 minutes.

5. One real payment, made by you

Before you announce anything, buy something from your own shop with a real card, for a small amount, and then refund it. This is the only test that exercises your actual bank contract.

Check the whole chain: the payment shows as completed, your order moved to paid, the webhook was delivered, the fiscal receipt was issued if you use e-HDM, and the refund went back cleanly.

While you are at it: e-HDM

If you sell to consumers in Armenia you need fiscal receipts, and it is easier to have that working on day one than to retrofit it. Connect your e-HDM in the dashboard, turn on automatic receipts, and every successful payment produces a receipt with its verification QR code. Receipts for payments taken through Paynet are free.

Do one manual receipt during setup and read it. A wrong tax regime produces legally incorrect receipts, and the setup is the moment to catch that.

What it costs to test

Nothing. Test payments are free and unlimited, for verified and unverified accounts alike. Failed payments cost nothing, and refunds are free. On the live side, Paynet charges 20 AMD per successful payment, payments under 500 AMD are free, and every new account starts with 200 free transactions and 500 free receipts that never expire. See the pricing page.

What to do next

1. Find your Default test key in the dashboard, or create one, and put it in an environment variable.
2. Install the Sandbox provider and turn it on for your domain.
3. Run the six cases above, including the abandoned payment and the duplicate webhook.
4. Verify your domain, submit your business documents, and add your real provider credentials while the review runs.
5. Send a test webhook, then make one small real payment and refund it.

The developer guide has the quick start, and the plugins page covers the no-code route if you would rather not build the integration yourself.

Idram, Telcell, ARCA and the bank names mentioned belong to their respective owners. Paynet is an independent payment gateway.