curl --request POST \
--url https://api.next.orenda.finance/v1/customers/{customerId}/accounts/{accountId}/cards \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"cardType": "VIRTUAL",
"nickName": "Online subscriptions",
"limitGroupId": "lg_2b4d6f8a"
}
'{
"success": true,
"data": {
"id": "crd_9f2a1c4b",
"status": "CREATED",
"cardType": "CONSUMER",
"format": "VIRTUAL",
"maskedPan": "•••• •••• •••• 4242",
"cardScheme": "VISA",
"cvv": "***",
"expiryDate": "12/29",
"currency": "GBP",
"nickName": "Online subscriptions",
"limitGroupId": "lg_2b4d6f8a",
"accountType": "CONSUMER",
"createdAt": "2026-06-18T10:32:00Z"
}
}Create a card
Issues a new card on the account. Send either cardType (VIRTUAL or PHYSICAL) or cardName (a product from Get card options), not both. The card comes back as CREATED; activate it before it can be used.
Send an Idempotency-Key and reuse it on a retry. Creation charges a setup fee and provisions a card at the issuer, so a blind retry without a key can leave the customer with two cards and two fees. While the first request is still provisioning, a retry with the same key returns 409 IDEMPOTENT_REQUEST_IN_PROGRESS: back off and retry with the same key. Don’t drop the key and resend, or you’ll issue a second card.
curl --request POST \
--url https://api.next.orenda.finance/v1/customers/{customerId}/accounts/{accountId}/cards \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"cardType": "VIRTUAL",
"nickName": "Online subscriptions",
"limitGroupId": "lg_2b4d6f8a"
}
'{
"success": true,
"data": {
"id": "crd_9f2a1c4b",
"status": "CREATED",
"cardType": "CONSUMER",
"format": "VIRTUAL",
"maskedPan": "•••• •••• •••• 4242",
"cardScheme": "VISA",
"cvv": "***",
"expiryDate": "12/29",
"currency": "GBP",
"nickName": "Online subscriptions",
"limitGroupId": "lg_2b4d6f8a",
"accountType": "CONSUMER",
"createdAt": "2026-06-18T10:32:00Z"
}
}Authorizations
The user's access_token from authentication. The program and environment come from the token.
Headers
Optional. Makes the request retry-safe: a retry with the same key resolves to the same card instead of creating a duplicate. Must be a UUID, and is scoped to the authenticated customer. Preferred over any idempotencyKey body field (a header value wins if both are sent). Optional today, but will be required in a future release: send one on every create now so a retry can never produce a duplicate.
Path Parameters
The customer's id.
The account the card belongs to. A customer can have several accounts; cards are issued against one.
Body
The card format. Send this or cardName.
VIRTUAL, PHYSICAL A configured card product. Send this or cardType.
Optional label shown to the user.
Optional. Initial limit group.
Optional. Issue as a prepaid card (where the program supports it).
Optional. The cardholder, for corporate cards. For a management/M2M caller ordering on a corporate's account, naming a cardholder of that corporate (invited as an EMPLOYEE, or under a role your program defines) makes it that cardholder's card: embossed with their name and attributed to them, so among cardholders only they see it; what they can do with it is set by the permissions on their role. The cardholder must belong to the path corporate, and — when they were granted specific accounts — the path account must be one of them; otherwise 400.
Optional. Idempotency key for retry-safety. The Idempotency-Key header is preferred and overrides this field. Reusing a key with different core parameters returns 400; a key whose card is still being claimed returns 409.