How the mock behaves

The mock keeps real state, so what you create is what you read back. There are two ways to complete a payment: the user journey on the hosted payment pages (the default), or, for a headless test, the MOTO route below.

Completing a payment through the API (MOTO)

Create the payment with "authorisation_mode": "moto_api" (and no return_url). The response has an auth_url_post link containing a one_time_token. Send the token and card details to POST /v1/auth:

curl -X POST https://publicapi.payments.platform-engineering.com/v1/auth \
  -H "Content-Type: application/json" \
  -d '{"one_time_token":"...","card_number":"4444333322221111",
       "cardholder_name":"A Tester","cvc":"123","expiry_date":"12/30"}'

The payment moves created, started, submitted, then success (or capturable if delayed_capture is true). Each change is recorded as an event.

Test cards

Card numberResult
4000000000000002Declined: 402, payment fails with code P0010
Any other 12 to 19 digit number, for example 4444333322221111Succeeds

Other behaviour

  • Web payments (the default mode) complete on the hosted payment pages: redirect the user to next_url, they choose an outcome, and they return to your return_url.
  • Webhooks send signed messages when a payment succeeds, is captured, fails, is cancelled or is refunded. See Webhooks.
  • Cancel works while a payment is created, started or capturable. Capture needs capturable.
  • Refunds need a payment in success. A refund reads as submitted for 5 seconds, then success. The payment's refund_summary updates straight away.
  • Agreements start as created. Create a payment with set_up_agreement set to the agreement ID and complete it: the agreement becomes active. Then payments with authorisation_mode: agreement succeed immediately. Unlike the real service, a created agreement can be cancelled.
  • Disputes are four fixed samples, because real disputes come from card schemes.
  • Search supports the documented filters, page and display_size, with navigation links.
  • Not implemented: rate limiting (429), real card entry, and real card validation beyond basic format.