Testing

Force any outcome on demand, including the ones that are hard to reproduce.

Sandbox payments accept a metadata.simulate directive, so you can test the paths a real bank will not reproduce on request.

Value	Result
`settle`	Succeeds after about a second
`slow_settle`	Succeeds after 30 seconds, stands in for Multibanco
`cancel`	Customer abandons it
`fail`	Bank declines it
`expire`	Customer never completes it
`decline_create`	Rejected before a redirect is issued
`timeout_create`	The create call hangs and times out; exercise your retry handling

To rehearse failover, metadata.simulate_fail_on names the MID that should refuse the payment; routing then cascades to the next one, which is exactly what a real outage looks like from your side.

{
  "method": "ideal",
  "amount": 1050,
  "currency": "EUR",
  "country": "NL",
  "success_url": "https://shop.example.com/thanks",
  "error_url": "https://shop.example.com/failed",
  "metadata": { "simulate": "slow_settle" }
}

Omit the directive and the redirect leads to a page with buttons, so you can walk the flow by hand.

Test cards

Card payments in the sandbox choose their outcome from the card number. Any future expiry and any CVC work. The scheme is read from the number, so use the column matching a scheme enabled on your account — a Mastercard-only account pays with the Mastercard numbers.

Visa	Mastercard	Result
`4242 4242 4242 4242`	`5555 5555 5555 4444`	Succeeds and settles immediately
`4000 0000 0000 0002`	`5105 1051 0510 5100`	Declined by the bank
`4000 0000 0000 3220`	`5200 8282 8282 8210`	3-D Secure challenge — complete it with verification code `123456`

Any other valid card number authorises and settles a moment later over the notification path, like a real acquirer.

Test the slow path. Multibanco customers pay at a cash machine, sometimes days later. Integrations that assume settlement follows the redirect within seconds break on it, and slow_settle is how you find that before a customer does.

PreviousAuthentication NextAccepting payments