Skip to main content
This page is part of Supported Payment Methods. View all payment methods →
CardPay displays a secure card entry form where customers enter their card details. The form handles validation, formatting, and card brand detection automatically.

​
Availability

CardPay is available on all browsers and devices. It appears in checkAvailability() results when properly configured.

​
Requirements

CardPay requires:

​
Button Setup

​
How It Works

  1. Customer clicks the CardPay button
  2. A secure popup window opens with the card entry form
  3. Customer enters card number, expiry, CVV, and name
  4. The form validates input in real-time
  5. If 3D Secure is required, the authentication flow is handled automatically with no additional code required
  6. Orchestra processes the payment through your PSP
  7. On completion, the popup closes and results are returned to the client, ready to be sent to your server for validation

​
Supported Operations

​
Stored Cards (Returning Customers)

CardPay can offer returning customers their previously tokenized cards. Pass up to 3 stored cards in the session; the card entry form then shows a “Pay by {brand} ****{last 4}” button per card alongside the option to enter another card. When the customer selects a stored card, they enter only its CVV, and the charge runs against the real card resolved from the token.
Where the display details come from: store the non-sensitive card details from the tokenization result when you first tokenize the card - tokenAndMaskedCardModel.bankCard contains the brand (type), masked number (take the last 4 digits), expirationMonth, expirationYear, and nameOnCard (see Result Handling). This is the only source: these details cannot be retrieved later, so persist them alongside the token. Rules and behavior:
  • Maximum 3 stored cards per session; not allowed with the TOKENIZE operation.
  • Each token must belong to your account, and cards whose supplied expiration date has passed are rejected at session creation.
  • The display details are shown to the customer exactly as you provide them and are not validated against the card behind the token. Keeping the token-to-card mapping correct in your system is your responsibility.
  • A payment made with a stored card in a CHARGE_AND_TOKENIZE or PREAUTH_AND_TOKENIZE session is not tokenized again, and the result contains no new token.

​
3D Secure

3D Secure is triggered when:
  • Your CardPay eWallet account is configured to require 3DS, AND
  • Your PSP integration in Orchestra supports passing 3DS data (see supported 3DS integrations)
When both conditions are met, the library handles the entire 3DS challenge flow automatically with no additional code required. See 3D Secure for more details.

PSP Setup

Configure payment processor credentials

Result Handling

Parse payment results

3D Secure

Authentication details