BNPL Refunds

BNPL Refunds allow the reversal of payments made using BNPL. Multiple partial refunds can also be created up to the amount of the original payment request.

info

Please note that refunds can only be made for BNPL pay-ins, and will be to the same destination from which the pay-in originated. The destination for a refund cannot be changed.

To issue a refund, the following conditions should be met:

• The payment request must be in the PaymentRequestCompleted state.
• The refund amount must be less than or equal to the original payment amount.
• The refund amount (if partial) must not exceed the original payment amount less any previously processed partial refund amounts.

Refund creation is protected by a client token. You'll need to follow the steps described in the client token guide to obtain a client token with the client_refund scope.

The GraphQL API URL https://api.stitch.money/graphql can be used for all refund requests (whether on test or live clients).

Creating a BNPL Refund

The GraphQL mutation shown below should be used to create BNPL refunds, and includes the following input values:

• The unique Stitch ID (originalPaymentId) of the original payment request being refunded,
• The requested refund amount (refundInput.amount), that should be less than, or equal to, the original amount,
• An appropriate refund reason (refundInput.reason),
• A nonce value (refundInput.nonce) that uniquely identifies the refund request, and
• An optional reference (refundInput.externalReference) to associate to the refund.

Refund Statuses

The table below describes the different statuses of a BNPL refund:

Status	Description
TransactionPending	A refund transaction is initialised and awaiting processing, due to a timeout or delay in status confirmation downstream from Stitch.
TransactionFailure	A refund transaction failed to be initiated, and funds were not reversed, due to the associated reason field.
TransactionSuccess	A refund transaction was successfully initiated, and the requested amount will be reversed to the initial transaction's source.

Failure Reasons

The TransactionFailure status indicates that the refund failed to be initiated, and includes a reason explaining the cause. Potential failure reasons are detailed below:

Reason	Description
exceedsOriginalAmount	The refund amount exceeds the original transaction amount, or outstanding refundable amount (after previously processed partial refunds).
internalServerError	The transaction could not be processed due to a server error.
invalidConfigurationError	The client has invalid or missing configuration.
paymentRefundFailed	The refund transaction could not be processed.

Querying Refunds

Refund by ID

For implementing redundancy checks and logic, it is possible to query refund transaction statuses and details over the Stitch GraphQL API. Note that querying with the Stitch-provided id is the most performant, and the recommended approach.

Webhook Subscriptions

BNPL refunds require that you subscribe to transaction webhooks to receive asynchronous updates on refund transaction status changes.

If the subscription is successfully created, the body returned by the request will look similar to the sample in the Example Response tab in the widget above.

For more information on receiving webhook events, listing active webhook subscriptions, unsubscribing from webhooks and validating signed webhook subscriptions, please visit the Webhooks page.

Webhook Statuses

When subscribed to the transaction webhook filter type, webhook updates will be sent whenever a transaction is updated to either of the following final statuses:

• TransactionSuccess
• TransactionFailure

Postman Collection

BNPL refunds can be created and tested using the Postman collection available here. These can be used by specifying your client credentials and supplying the custom request variables where required.