Who this is for. Developers testing a checkout or a payment form, and whoever signs a site off for launch. After this page you can use Mock Pay to exercise the success and decline paths, and prove that no live site offers it.
Unit 04 · Taking payment
The mock provider
Mock Pay is the test provider: it reports payments as successful and moves no money, and it must never be active on a live site. Its settings, how to test with it, and the check that proves it is off before launch.
Mock Pay must never be selectable on a live site
Mock Pay takes no money, yet every order it produces has the same shape as a real one to fulfilment, stock, reporting and every system that reads orders. One active Mock Pay method on a live site means goods shipped and services delivered for payments that never happened.
What Mock Pay does
Mock Pay is a payment method like the other three. It is created under Invoices › Payment methods, offered in the admin on every environment, listed by the payment-methods API when it is active, and run by the purchase call in the same way as a real provider. No request leaves the site: the provider is simulated inside the platform. With its default settings it reports every payment as successful.
Because it is registered exactly like the real providers, keeping it off a live site is a check that people make. That is why the check below belongs in every launch.
Its settings
| Setting | Values | What it does |
|---|---|---|
| Failure Rate | never (the default), random, always | never: every payment succeeds. random: each payment succeeds or fails on an even chance, one in two. always: every payment fails |
| Authorization | Switch | On: the method can authorise a payment, then capture or void it later. Off: authorising, capturing and voiding are refused, so it behaves like a provider that only takes the money in one step |
| Partial Capture | Switch | Whether an authorised payment can be captured in part |
| Refunds | Switch | Whether its payments can be refunded |
Testing with it
- Run the whole checkout on a development site with Failure Rate
never, and confirm the order, the order-complete page and the confirmation email. - Set it to
alwaysto test the decline path: the message, the form left filled in, and a second attempt (3-D Secure, declines and retries). - Use
randomto meet both paths in one session; expect about half the payments to fail. - Turn Authorization off to test against the shape of a provider that captures in one step.
The check before launch
Make this check before every launch, and again after any change to payment methods. The payment-methods list covers every site on the account (Listing the methods a shopper can choose), so check every site's methods, not only the one you are launching.
- In the admin, open Invoices › Payment methods for every site of the account, and open each method. No Mock Pay method may be Active.
- Request
GET https://<live host>/cdna-api/invoices/payment-methods?active=1, the same list the checkout reads. No entry may have"paymentServiceProviderType":"mock-pay". A Mock Pay entry also shows itsfailureRate, so the answer tells you what such a method would do. - Open every form with a payment element and check that none offers a Mock Pay method.
- Deactivate or delete any Mock Pay method you find, then place one small real payment on the live site to confirm that the live method works.
A second guard in your script
Build the live site's payment script with modules only for the providers it uses. A dispatcher that loads a module per provider type, and lists only the types it has a module for, never draws a Mock Pay option (The client-side handler). The check above still applies, because forms and every other site of the account have their own payment steps.
Go deeper
Was this page helpful?
Your answer goes to the docs team.