Request a subsequent unscheduled payment.
The ID of the initial payment
The amount given in minor units (e.g. use 700 for 7€). Some currencies do not support minor units (e.g. Japanese Yen). In this case send in the full value, .i.e. 100 for 100 JPY.
x >= 0A description of the payment for later reference
80The preference for the authentication method to be used for the payment.
| Preference | Description |
|---|---|
| NO_3RI | Don't perform 3RI authentication for this payment (Default). |
| TRY_3RI | Try to perform 3RI authentication for this payment. If it fails the payment will still be sent for authorization. |
| REQUIRE_3RI | Require 3RI authentication for this payment. If it fails the payment will not be sent for authorization. |
NO_3RI, TRY_3RI, REQUIRE_3RI Metadata consisting of entries, each of which each includes a key and an associated value:
{
"my_key_one": "my_value_one",
"my_key_two": "my_value_two"
}Success response
The ID of the payment on Commerce
The date-time the payment was created (following ISO 8601)
A description of the payment for later reference
80open, processing, failed, authorized, capturing, captured, settling, settled, voiding, voided Definition of the payment use-case for processing
ONE_OFF, UNSCHEDULED, SUBSEQUENT_UNSCHEDULED, RECURRING, SUBSEQUENT_RECURRING The preference for the authentication method to be used for the payment.
| Preference | Description |
|---|---|
| NO_3RI | Don't perform 3RI authentication for this payment (Default). |
| TRY_3RI | Try to perform 3RI authentication for this payment. If it fails the payment will still be sent for authorization. |
| REQUIRE_3RI | Require 3RI authentication for this payment. If it fails the payment will not be sent for authorization. |
NO_3RI, TRY_3RI, REQUIRE_3RI The final result of the authentication. It holds in the cardholder authentication data (CAVV) and if there is a network token present, the token authentication data (TAVV).
The ID of the credential associated with the payment.
The reasons why a payment failed during processing in Commerce.
This can be due to processing errors on the side of the processor, as well as errors in the processing of the underlying flow.
In case the failure is due to a processing problem, the transaction history of the payment can give more information on the exact failure details.
The rule in the flow matrix, which was chosen to process the payment.
The ID of the initial payment.
Only present for subsequent merchant-initiated payments.
This is an optional attribute holding results from eventual pre-processing of the request.
The date when the recurring should expiry.
Only present for recurring payments.
Indicates the minimum number of days between authorisations.
Only present for recurring payments.
The source that was used for the payment.
| Type | Description |
|---|---|
card | The payment method card was used as source |
An array of split instructions.
Data in this array is only processed on a Commerce account in the platform operating model. If you are in doubt, please reach out to your account representative.
| Type | Description |
|---|---|
| seller | Sending the given amount to the seller referenced by the merchant_id in the payload. The seller needs to be onboarded to the account and linked to the processor in order to receive funds from a payment split. |
| commission | An already existing Commerce token can be used as source for the payment. |
1Metadata consisting of entries, each of which each includes a key and an associated value:
{
"my_key_one": "my_value_one",
"my_key_two": "my_value_two"
}