Issue a full or partial refund for a previously settled payment. By default, the full amount will be refunded unless a specific amount is provided for a partial refund.
If the payment was partially captured multiple times, you can specify which capture to
refund by using the transaction event ID. Refer to the transactions.events array in the
payment object to find available transaction event IDs (when the appropriate expand
parameter is passed).
When specifying a transaction event ID, the refund amount should not exceed the amount captured in that event. If no refund amount is provided, it defaults to the amount captured in that specific event.
ID of payment to refund.
Optional key to make the request idempotent. Enables a safe retry of a request without risking the user being charged or refunded multiple times. The idempotency key must be generated by the client and needs to be unique for every new request.
The amount you would like to refund the customer, in minor units. e.g. for $7, use 700.
Defaults to remaining non-refunded amount.
Optionally you can pass a specific order ID for the refund.
By default this will be set to the original orderId given on payment creation.
You can optionally specify a reason for the refund. This is for your own records.
Specific capture ID to target for the refund. Use this to specify which transaction event the refund should apply to.
A list of fields to expand, such as transactions.events.
Successful Response
The unique payment ID.
You can use this ID to retrieve the payment details, or perform downstream operations.
The date and time at which the payment was created in UTC format.
The date and time of the last payment update in UTC format.
The type of card token used for the payment.
Only applies for card payments.
Your reference for the payment.
The amount you charged the customer, in minor units.
More information associated with the order.
The unique identifier for your customer.
More information associated with the customer.
Additional data to be used throughout the payment lifecycle.
The payment method options provided in the request, as well as the token used to process the payment.
More information associated with the payment processor, including the processor name.
Required action to perform in order to resume the payment workflow. This can be requiring a 3DS check from the customer for instance.
Check this field for more information regarding the payment’s status. This is especially useful when the status is DECLINED or FAILED.
A list summarizing the transactions that occurred while processing the payment.
Note: a refund is a separate transaction and so will appear in this transactions list if a refund was performed.
Risk data associated with this payment.