Determines the type of the authorization that will be used. Allowed values:
PRE_AUTHORIZATION - The payment creation results in a pre-authorization (reservation) of the payment amount that is ready for capture. Pre-authorizations can be reversed and can usually be captured within 30 days. The capture amount can be lower than the authorized amount.
SALE - The payment creation results in an authorization that is directly captured at the moment of approval.
recurring.recurringPaymentSequenceIndicator
Determines the series of a recurring card on file transaction. Allowed values:
first - Should be provided if the transaction is the first of a series of recurring transactions. Usually requires a strong customer authentication.
recurring - Should be provided if the transaction is a subsequent transaction in a series of recurring transactions and a previous card on file agreement with an initial successful strong customer authentication has occured.
paymentProcessingToken
String of the token that is required to initiate the payment. Will be created during the creditcardcheck request using a separate integration (see documentation below)
transactionChannel
Indicates the channel via which the payment is created. Allowed values:
ECOMMERCE - The transaction is a regular E-Commerce transaction.
MOTO - The transaction is a Mail Order/Telephone Order.
unscheduledCardOnFileRequestor
Determines the initiator of the an unscheduled card on file transaction. Allowed values:
merchantInitiated - The merchant has initiated the transaction meaning that the customer usually is not present.
cardholderInitiated - The cardholer has initiated the transaction (e.g. One-Click transactions).
unscheduledCardOnFileSequenceIndicator
Determines the series of an unscheduled card on file transaction. Allowed values:
first - Should be provided if the transaction is the first of a series of unscheduled transactions. Usually requires a strong customer authentication.
subsequent - Should be provided if the transaction is a subsequent transaction in a series of unscheduled transactions and a previous card on file agreement with an initial successful strong customer authentication has occured.
paymentProductId
Payment product identifier - see above for a full overview of possible values. The cardType of the credit card is part of the response of the creditcardcheck.
card.cardholderName
The card holder's name on the card.
returnUrl
The URL that the customer is redirect to after the payment flow has finished.
Important remark: The Commerce Platform does not handle clear PANs, credit card payment will be done only with a token (paymentProcessingToken). In order to create the paymentProcessingToken, a separate integration is required. A step by step guide for the integration on the test environment as well as for production can be found below.
---end
Integration on test environment
The following steps are also implemented in our SDKs. If you are using those, please head over to our Integration Guide.
Step 1: JWT Token Generation
Create a Json Web Token
Creating a JWT needed for later authentication within JS form when is being submitted for card processing.
POST JWT Request
Request - Empty Body /v1/{merchantId}/authentication-tokens
You can identify the corresponding transaction by the field createPaymentResponse.payment.id in the order response. The status PENDING_CAPTURE shows that the amount is authorized and the payment gateway is waiting for a capture.