Attempts to void a payment.
Commerce will attempt to interrupt the payment processing and reverse the transaction.
However, this operation may not always succeed due to limitations imposed by specific payment methods or providers. If the void operation is not possible, the payment will continue processing until it reaches its terminal state (e.g., successful completion or failure).
The operation is asynchronous such that the result will be communicated via a notifcation.
The ID of the payment on Commerce.
Cancel accepted
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"
}