Initiating Refunds

Refunds are initiated by calling the Refund Payment Request endpoint.

Refunds can be partial or full. Partial refunds can be performed multiple times but the total refunded amount cannot exceed the paid amount.

Refund Idempotency

Refund requests must provide an externalRef that is unique for all refunds made against the Payment Request .

This field provides idempotency for the refund operation and ensures that a refund can be retried safely and only one refund will be actioned. Subsequent refund requests with the same amount and externalRef will respond with HTTP 200 OK.

Obtaining a Payment Request Id

Refunds are initiated using the id of the Payment Request . A patron should have either the id or the shortCode available. Merchants can obtain the id by looking the Payment Request up by shortCode.

POS systems or digital wallets that support transacting with Centrapay should make the id or shortCode fields discoverable through the user's transaction history, or through a paper receipt, so they can be used to negotiate refunds.

By Short Code

Call the Get Payment Request by Short Code endpoint using the Centrapay short code that the patron obtains from their paper receipt or digital wallet transaction history.

    sequenceDiagram
	autonumber

	participant P as Patron
	participant POS
	participant C as Centrapay

	P->>POS: Patron Presents Short Code
	POS->>C: Get Payment Request by Short Code
	POS->>C: Refund Payment Request
  

Refund Error Handling

There are a number of reasons why initiating a refund can fail. These are documented on the Refund Payment Request endpoint and should be communicated to the user.

Refunds that encounter unknown errors should be retried as per Merchant Integration Error Handling .

When retrying unknown errors is impossible, POS operators may need to select a different refund method.