Skip to main content

Softpay sandbox environment and test cards

How the Softpay sandbox works in broad strokes — the Ajax (mock acquirer) and Acme (Nets) packages, how to tell which one you are on, how to use test cards, and what the sandbox does not do.

Softpay sandbox environment and test cards

The sandbox is our test environment. It behaves like the real Softpay setup — you log in to the app, take payments, get receipts and transaction results — but no real money ever moves, and no real cards are involved. It is where you build and verify your integration before you go live with a merchant.

This article explains the sandbox in broad strokes. The detailed technical specifications live on our developer site.

Two sandbox packages

Softpay offers two separate sandbox packages. They look the same from the app, but what happens behind the payment is different.

Ajax — the default

Ajax is the sandbox package we set up as the default since April 2026, and the one we recommend for day-to-day development and testing.

  • It is connected to our mock acquirer — a simulated payment backend that we run ourselves. ("Acquirer" is the party that would normally process the payment and move the money.)

  • It accepts any test card, so you do not need a card tied to a specific bank or acquirer.

  • It uses "magic numbers": the amount you enter decides the outcome. A specific amount triggers a specific outcome — an approval, a decline, and a range of other scenarios you need to test against. The full list of amounts and what each one triggers is in the sandbox testing documentation.

  • Because it runs entirely on Softpay infrastructure, it is not affected by third-party maintenance windows.

For the finer details of this package — how merchant and terminal IDs are formed, and the known limitations — see Key configurations and limitations of the MockPI sandbox environment.

Acme — end-to-end with Nets

Acme is connected to Nets and their own sandbox environment. Instead of a simulated backend, your test payments travel through a real processing and acquiring chain, which makes it useful when you need to see a full end-to-end flow rather than a simulated result.
​

Please note: because Acme depends on an external sandbox that Softpay does not operate, it is regularly subject to change and maintenance, and it can be unavailable for extended periods. That downtime is outside our control, and we cannot give a fixed timeline for when it will be back. If your testing does not specifically require the Nets chain, use Ajax instead.

Which one am I on?

The app tells you. When you take a payment, the merchant name shown on screen always starts with the package name, followed by the company name you signed up with on the developer site — so a company signed up as Merchant appears as Ajaxmerchant on Ajax and Acmemerchant on Acme.
​

New integrators are set up on Ajax by default. If you need access to the other package, contact your Softpay provider.

Using test cards

To make a test payment in the sandbox, you need a test card — a physical card issued for testing that carries no real funds and no real cardholder.

  • Use test cards from Visa, Mastercard, or any other card scheme supported by Softpay.

  • If you already have test cards from another card terminal solution, or from an acquirer or bank you work with, they will in most cases work in Softpay too.

  • Softpay does not issue or supply test cards. You obtain them from a card scheme, an acquirer, or your bank.

Never mix real cards and the test environment

  • Do not use real cards in the sandbox. It will not work — but more importantly, it can expose real card data in a non-production environment.

  • Do not use test cards in production. They will not work there either.

Visa Mobile CDET (third-party alternative)

If you do not have a physical test card, some integrators use the Visa Mobile CDET app to emulate a contactless test card on a second Android phone with NFC. You install the app on that phone and tap the two phones together to make a payment.

Important: CDET is Visa's application, not Softpay's. We do not develop it, distribute it, or provide support for it, and we have no visibility into how it behaves. If CDET shows an error, fails to emulate a card, or stops working after an update, Softpay is not able to troubleshoot or resolve it. We mention CDET only because integrators have found it useful; a physical test card remains the reliable option.

What the sandbox does not do

  • No money moves. Nothing is captured, settled, or paid out. Sandbox transactions never appear on a real statement.

  • Data is not realistic everywhere. On the mock acquirer, masked card data can look unusual and does not follow real card number patterns. This is expected, not a fault.

  • It is a test environment. Sandbox data can be reset or changed, and it is not intended for demos to end customers or for any kind of live use.

Next steps

Did this answer your question?