Ordering cards

After creating a profile, cards can now be ordered. The first step is to retrieve the available card programs. A card program gives information on the type of card, the network that the card is on, as well as the default currency of the card.

If there are no card programs returned in the API call, it means that the profile cannot order any additional cards.

• Virtual - No physical card will be printed. This card can be used for online transactions and added to digital wallets.
• Physical - A physical card will be printed. On top of virtual card capabilities, physical cards can also be used at physical terminals and ATMs.

After retrieving the card program, use the card order API to create a card order. It is also best practice to use the card address validation API to ensure the formatting of the address is correct.

The address is required for both virtual and physical cards as it will be used for AVS (address verification service) checks for transactions without a card present.

When the status of the card order is CARD_DETAILS_CREATED, a card will now be available to be retrieved.

The card token is the unique identifier for this card.

For physical card orders, it is recommended to subscribe to the card order status change webhook event to be notified of card order status changes.

You can cancel a card order by updating the card order status to CANCELLED with a reason. This can only be done when the card order is still in the PLACED status.

In order to control the number of cards a profile can create, we have card order limits in place. On production, the number of card orders is limited to 1 active physical card and 3 active virtual cards per personal profile. On sandbox, we allow up 10 physical cards and 30 virtual cards for testing. Additionally, no more than 3 virtual cards can be ordered per day. This limit includes existing cards and card orders.

Retrieving the sensitive card details (PAN, PIN, CVV) of a card requires us to do so in a PCI-DSS compliant way, follow our sensitive card details guide on how to do so.

Card PIN

Some card terminals and ATMs require users to enter their card PIN to authenticate transactions. By default, both physical and virtual card PINs are randomly set.

Optionally, we offer a feature to pre-set the PIN of the card during the card order process. Reach out to your account manager for this feature as Wise will first need to configure this to be done on our side.

To mitigate the possibility of fraudulent transactions on the card in the event of misdelivery of the card, users need to verify they have received their physical card before they can perform contactless and magnetic stripe transactions. There are two available options to verify that the user has received their physical card: Chip and PIN transactions and Partner Control.

Prior to verification, POS_CONTACTLESS and POS_MAGSTRIPE spending permissions will be locked and disabled for physical cards, meaning these permissions cannot be enabled at that point.

Contactless and magnetic stripe transactions that are attempted when the card order status is not COMPLETED will be declined.

Users wanting to use their physical card for contactless and magnetic stripe transactions will have to first make a Chip and PIN transaction (inserting the card into the terminal and keying in the card PIN). This flow applies to cards with unlockSpendingPermissions as WITH_FIRST_CHIP_AND_PIN_TRANSACTION.

After this, the card order status will be moved to COMPLETED, unlocking and enabling contactless and magnetic stripe transactions. Users can choose to toggle these spending permissions using the modify spending permissions API.

If partner control is supported in your integration, you can update the card order status to COMPLETED when your end user has received their card. This flow applies to cards with unlockSpendingPermissions as WITH_PARTNER_API. Updating the status to COMPLETED will allow contactless and magnetic stripe permissions to be unlocked, and the user can then enable them.

As all spending permissions are by default disabled for this integration type, you will need to call the modify spending permissions API to enable the unlocked permissions after updating the card order status. We recommend to update the status to COMPLETED only after ensuring that your end user has received their physical card. This can be ascertained through the following methods:

1. Validate last 4 digits: In this flow, the card details such as PAN should initially be hidden from the end customer. You can add an additional step requiring end customer to key in the last 4 digits of their physical card upon receiving it. This can be validated against the lastFourDigits in the Card resource. Since card details would initially be hidden from the end user, this means that they cannot perform transactions requiring the PAN until they have received their physical card, even if digital spending permissions are enabled.

2. Partner Chip and PIN: You can implement your own Chip and PIN flow to ensure your end user has access to their physical card. In Wise, the following fields are checked to validate that the transaction is sufficient to unlock physical spending permissions. These are available in the card transaction state change webhook.

• transaction_type is one of POS_PURCHASE or CASH_WITHDRAWAL
• transaction_state is one of IN_PROGRESS or COMPLETED
• pin_validation_result is one of ONLINE_PIN_VALIDATED or OFFLINE_PIN_VALIDATED
• authorisation_method is CHIP_AND_PIN