Create a single-use token

post

https://sandbox.comcarde.com/v1/payment-instruments/single-use

For one off payments you can exchange cardholder data for a single-use token that can be used as a payment instrument via the Tokenized Payment Flow

Card on File multi-use tokens can also be exchanged for single-use tokens. This can be useful if you wish to include CVV values in your payments as this data cannot be stored with Card on File.

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Body Params

Payment instrument to be tokenized (cardholder data or Card on File multi-use token)

Payment instrument that is a credit or debit card.

type

string

required

Discriminator field. Please see the discriminator mapping for the PaymentInstrumentRequest schema.

customerId

string

length between 1 and 100

^([\p{L}\p{M} 0-9'\[\]()@?!\-/.,_&*:;+=`]*)$

Identifier for the merchant's customer who owns the payment instrument to be tokenized.

customMetadata

object

Optional custom metadata string fields for the payment instrument.

Up to 25 fields can be included with the following constraints:

The field name may not be empty or have leading or trailing whitespace, and can consist of upper and lowercase letters, numbers, space, underscore "_", hyphen "-" and single quote "'".

Maximum string length of either field name and field value is 200 chars.

address

object

nameOnCard

string

length between 1 and 255

^([\p{L}\p{M} 0-9'\[\]()@?!\-/.,_&*:;+=`]*)$

Name on the credit or debit card. This may be required by the payment services provider (PSP).

pan

string

required

PAN of the credit or debit card.

expiryDate

string

required

Card expiry date in MM-YY format.

startDate

string

Start date of the credit or debit card.

issueNumber

int32

1 to 9

Issue number of the credit or debit card.

cv2

string

[0-9]*$

pspTokens

array of objects, unique

A set of PSP tokens linked to this Card-on-File

pspTokens

storedCredentialIndicator

string

enum

Indicates whether a card has been stored externally to our system,
and if it has been used previously.

Used for the situation where you have previously used and stored the card outside
our system. This will override the value sent to the card networks, (e.g. Visa/Mastercard)
on the first time the card is used within our systems.

If your systems don't ever store card details this field should be ignored.

When sent to us this affects the first time the tokenized card is used within our systems.
In the case of a card that you never want tokenized with us, but is tokenized externally,
we will require the correct value on every call.

This is related to Credential on file mandate compliance.

Possible Values

UNUSED - The card has not been previously used in a transaction,
this is used as a hint to the networks that the card will be stored from
this point onward.
USED - The card has been previously used in a transaction on your systems,
this lets the networks know that this is a previously stored card.

Usage Notes:

Not sending a value for this implies that you have not stored the card for reuse
within your systems.
If your company never stores cards for reuse then there is no need to ever send
a value for this field.
This field is optional but MUST be filled when using a previously/externally stored card.

Allowed:

networkTokenProvisioning

string

enum

Defaults to async

Whether to synchronously or asynchronously enroll and
provision a network token and optionally include the
cryptogram in the response when creating a card-on-file.

If unspecified and, if the retail channel is enabled for network
tokenization, the async behaviour will be used by default.

This field accepts the following values:

async
- Asynchronously enrolls a card, a network token card
  number will be available once a cryptogram is provisioned.
networkToken
- Synchronously enrolls a card and provisions a network token
  when creating the card-on-file.
networkTokenWithCryptogram
- Synchronously enrolls a card and provisions a network token
  when creating the card-on-file, providing the resulting
  cryptogram in the same response.

Allowed:

Responses

Possible Values

201Successful tokenization of payment instrument

400Unsuccessful tokenization of payment instrument - bad request