Skip to content

Test Cards

Exercise your integration end to end in the test environment before going live. The cards on this page belong to the providers’ test environments; they are not real cards and move no real money.

Test cards differ per the payment provider your terminal is connected to: one provider’s test card does not work with another and will be declined. Use only the cards under the heading of your own provider.

Brand Card number Expiry CVV 3D Secure password
Visa 4531444531442283 12/26 001 a
Mastercard 5818775818772285 12/26 001 a

The 3D Secure password is what the bank’s 3D verification page asks for after the card handoff. In the NestPay test environment it is a single character: a.

Brand Card number Expiry CVV 3D Secure code
Mastercard 5430811516419115 08/30 322 123456

In the HalkÖde test environment the 3D verification step asks for a 6-digit code (the SMS/OTP field); for the test card that code is 123456.

You can trigger different outcomes by changing the CVV or by behaving differently at the 3D step:

Scenario How to trigger Expected status
Successful payment Send the card with the values from your provider’s table, then complete the 3D step with the correct password/code captured
3D verification fails Enter a wrong password/code on the 3D page failed
Abandoning 3D Close the 3D page without completing it expired
Insufficient limit (NestPay only) Send 510 in the CVV field failed (bank decline)
Card closed to transactions (NestPay only) Send 000 in the CVV field failed (bank decline)
Timeout Create the payment and do not hand off for the whole window (30 minutes on NestPay; 135 minutes on HalkÖde terminals) expired

The CVV-triggered bank decline scenarios are specific to the NestPay test environment; they have no defined equivalents in the HalkÖde test environment — if you need to exercise a decline on HalkÖde, ask through your onboarding channel.

What the statuses mean and how they transition: Payment Lifecycle. What the declines map to: Error Codes.

Pick the card from the right provider’s set. A card from one provider’s test environment is not defined in the other’s; sending it results in a bank decline or a validation error. Every card-related rejection draws down that payment’s card attempt allowance.

Back-to-back 3D attempts get declined. The bank limits how many successful 3D transactions can be made within a 5-minute window; in rapid succession the third attempt may be declined. Leave a few minutes between attempts.

Installments. Start with a single charge (installment: 1) when using the test set. Installment transactions depend on card and terminal support; not every installment count is accepted with test cards. You can query the installment options defined for your terminal via Installment Options.

Do not read the result from returnUrl. What lands on returnUrl comes through the buyer’s browser and is not authoritative. While testing too, confirm the definitive result via GET /v1/payments or the webhook.

Send the card to the right surface. The card number does not go into the POST /v1/payments body; it is POSTed to the handoffUrl from the buyer’s browser only. Detail: Card Handoff.

  • Quickstart: create your first payment
  • Card Handoff: relaying the card to Lydia Gate 3DS Relay (web + mobile)