Authorisation and Direct Sale
The core of your integration solution is sending payment requests to our platform. When doing so, you can process them in two different authorisation modes: authorisation or direct sale mode.
Are you migrating from legacy to Direct and/or are you still using our legacy Back Office?
Mind that
- The legacy OPERATION parameter translates to Direct properties.
- Specific Back Office settings are (not) relevant for Direct transaction processing.
- e-Terminal/Pay by Link always process transactions in direct sale mode. However, using our Pay by Link solution via the PaymentLinks API does allow you define the authorisation mode via dedicated properties.
Authorisation mode
The appropriate mode depends on your business model and/or personal preference:
| Mode | Effect |
|---|---|
| Authorisation |
The card scheme/payment provider only blocks the amount you want to charge for the order on your customer’s card/bank account. Successful transactions will have status="PENDING_CAPTURE" / statusOutput.statusCategory="PENDING_MERCHANT" / statusOutput.statusCode=5. To actually receive the payment, you need to eventually capture this authorisation within a certain period. The validity period of an authorisation depends on various factors:
|
| Direct sale |
The card scheme/payment provider blocks and captures the amount you want to charge for the order on your customer’s card/bank account in one go. Thus, your customer’s bank is instructed to pay out the amount to you via your acquirer immediately. Successful transactions will have status="PENDING_CAPTURE" / statusOutput.statusCategory="PENDING_MERCHANT" / statusOutput.statusCode=9. Mind that processing transactions in direct sale mode does not mean you receive the funds instantaneously. The interval between a transaction reaching status 9 and receiving the funds depends on various factors:
|
Process requests
Our API implements specific properties for processing transactions in authorisation/direct sale mode. Add one of the properties to your CreatePayment (for Server-to-server integration method)/CreateHostedCheckout (for Hosted Checkout Page integration method) requests:
| Property | Remarks/Possible values |
|---|---|
|
cardPaymentMethodSpecificInput. mobilePaymentMethodSpecificInput. |
cardPaymentMethodSpecificInput.authorizationMode: Applicable to card payments (i.e. Visa). mobilePaymentMethodSpecificInput.authorizationMode: Applicable to mobile payments (i.e. Google Pay).
|
| redirectPaymentMethodSpecificInput. requiresApproval |
If you send "FINAL_AUTHORIZATION"/ "PRE_AUTHORIZATION", make sure to eventually capture the amount to actually receive the payment. Applicable to non-card payments (i.e. Paypal).
If you send "true", make sure to eventually capture the amount to actually receive the payment. |
- Mind that the availability of a specific authorisation mode/type, the validity period and the possibility for partial/multiple captures depends on various factors, such as
- The payment method/card scheme.
- Your customer's issuer.
- The location and type of your business.
- Your acquiring contract.
- The applicable property for your request depends on the payment method. Refer to JSON sample in the "Integration" chapters of the respective payment method documentation.