From sandbox to production: how to test a payment integration that doesn’t fail
A payment integration isn’t ready just because the first payment went through. Problems show up in the other cases, and catching them is exactly what a payment sandbox is for: an order created for a declined payment, a customer charged twice because they clicked “Pay” twice, or a paid Multibanco reference that still shows as “pending” in the store.
In that last case, the customer has paid but never gets an order confirmation; the order isn’t shipped; and the support team spends the day answering emails and fixing statuses by hand. All because the payment notification wasn’t processed correctly.
Sandbox vs. production: what changes
A payment sandbox is a test environment that works like the real payment platform, but without real money. At easypay, the difference lies in the API address and the credentials:
| Sandbox | Production | |
|---|---|---|
| API URL | https://api.test.easypay.pt/2.0 | https://api.prod.easypay.pt/2.0 |
| Real money | No | Yes |
| Credentials | Test credentials (available in the documentation) | Generated in your easypay account |
| Rate limits | More relaxed | Enforced |
| Data | May be reset | Permanent |
In practice, going live means switching the URL and the credentials. But a successful test in sandbox does not, on its own, guarantee that everything will work in production. Keep a close eye on your first real transactions.
The scenarios you need to test in your payment sandbox
1. Approved, declined and pending payments
Make sure a declined payment never results in a paid order, and that a pending payment isn’t treated as paid before it’s confirmed. Each payment method confirms payments differently, so test them one by one.
2. MB WAY: accepted, declined or expired
With MB WAY, the customer approves the payment on their phone. Test what happens when they accept, when they decline and when they don’t respond in time. Your store should release the stock, show a clear message and let the customer try again.
3. Cards: 3D Secure authentication, declines and captures
For cards, test approved and declined payments, but also 3D Secure authentication: what happens when the customer doesn’t complete the bank’s verification or closes the window halfway through. If you use separate authorisation and capture (for example, to charge only when the order ships), make sure the capture is for the right amount and that uncaptured authorisations aren’t forgotten.
4. Apple Pay, Google Pay and Samsung Pay: the right button on the right device
Digital wallets use one of the customer’s cards, so approved and declined payments and refunds work just as they do for cards. But there are specific tests to run: make sure each wallet’s button only appears on compatible devices and browsers, that the checkout still works when it doesn’t, and that your store’s domain is registered for Apple Pay. Also test what happens when the customer cancels the authentication on their phone (Face ID, fingerprint or passcode).
5. Virtual IBAN: transfers matched to the right customer
With a Virtual IBAN, each customer or invoice has its own IBAN, and the payment arrives by bank transfer: within seconds if it’s an instant transfer, or on the next business day if it’s a standard one. Test whether your integration correctly matches each transfer to the right customer or invoice.
6. Multibanco and other asynchronous payments
With a Multibanco reference, the payment can arrive hours or days after the customer has left the checkout. The order should only change status once the payment notification (webhook) arrives.
7. Duplicate, delayed or out-of-order notifications
Webhooks can arrive more than once, or in a different order than expected. Your integration should process each notification only once and always confirm the final payment status.
8. Network failures and repeated requests
What happens if the connection drops mid-payment, or the customer clicks the button twice? Use idempotency so that a repeated request doesn’t create a second payment.
9. Refunds, cancellations and captures
Test full and partial refunds, cancellations and, if you use separate authorisation and capture, the capture of authorised payments. Each operation must update the right status in your systems.
10. Credentials and data
Use test data only, keep sandbox and production credentials separate, and store them in environment variables or a secrets manager, never in your code.
How to test in the easypay payment sandbox
The easypay payment sandbox is free and lets you test Portuguese payment methods end to end:
- Cards: test card numbers to simulate approved and declined payments.
- MB WAY: test payments without confirming on a real phone.
- Multibanco: references you can mark as paid in the backoffice, to test asynchronous payments and notifications.
- Webhooks: receive status-change notifications just as in production.
To get started, just use the test credentials in the documentation and the sandbox URL:
curl -L -X POST 'https://api.test.easypay.pt/2.0/single' \
-H 'AccountId: <TEST_ACCOUNT_ID>' \
-H 'ApiKey: <TEST_API_KEY>' \
-H 'Content-Type: application/json' \
--data-raw '{ ... }'
If you use WooCommerce or Magento, you can also test the easypay plugins in test mode before enabling real payments.
Checklist before going live
- Every payment method in your store has been tested (cards, MB WAY, Multibanco, Virtual IBAN…).
- Declined, pending and expired payments leave the order in the right status.
- For cards, 3D Secure authentication and captures have been tested.
- Digital wallets (Apple Pay, Google Pay, Samsung Pay) have been tested on different devices and browsers.
- For Virtual IBAN, transfers are matched to the right customer.
- Webhooks are processed only once, even when duplicated or out of order.
- Repeated requests don’t create duplicate payments (idempotency).
- Refunds, cancellations and captures have been validated.
- Credentials and the URL have been switched to production.
- Monitoring and alerts are in place for the first real payments.
Whenever possible, automate these tests so you can rerun them every time the code changes.
Start testing today
A reliable integration starts before the first real payment. Use the test credentials and start now in the easypay sandbox, or talk to our team to find the right payment solution for your business.
[See documentation and test credentials] · [Request a proposal]