Refund Flow

Overview

Refunds can be initiated by an active user action (pressing the 'Refund' button) or can be triggered automatically on a user's behalf. Regardless of the trigger, an asynchronous refund request will be sent from Google to the payment integrator. The integrator must acknowledge the request, and notify Google once the refund is completed.

How the flow works

Refund flow

Here is an example asynchronous refund flow initiated by the user:

Here is the list of objects in the above diagram:

• User: This is the person who wants a complete or partial refund.
• Google Server: The backend server at Google that sends the refund command to the payment integrator.
• Payment Integrator: The integrator that forwards the refund request to the appropriate issuer.
• Issuer: The issuer used for payment, which accepts the refund request.

The refund in this example is initiated by the user.

1. User initiates the refund to the Google Server.
2. Google calls the AsynchronousRefund endpoint of the payment integrator.
3. The integrator sends an Acknowledged response to Google.
4. The integrator calls the appropriate Refund endpoint on the issuer.
5. The issuer processes the refund and responds to the integrator with Success.
6. The integrator calls the RefundResultNotification endpoint on the Google Server to notify Google of the result.
7. Google acknowledges the RefundResultNotification.
8. Google updates User's available funds.
9. The User gets a refund.

Best practices and other considerations

Because some Google products, such as Adwords, support refunds as long as credit in the account exists, transaction refund requests should be supported for an indefinite duration. If a technical limitation exists, the refund period should be as long as your platform allows.

Refunds can only be declined if the balance on the original transaction is not enough to cover the refund amount, or the account has been closed or is on hold and the integrator has no ability to send the user this money.

Refunds can be initiated within seconds after the capture. The timing of refunds is at Google's discretion.

A refund should never be assumed as a full refund. The refundAmount field must always be considered when refunding the account.

Multiple partial refunds must be supported. For example, let’s say a transaction worth $11.00 occurs, and a user can successfully obtain partial refunds of $4.00, $5.00 and $1.00 from the original transaction. In this case, all three refunds will have the same captureRequestId, but different requestId values. Further, this transaction would have just $1.00 left on it.

Now let’s imagine there is a $12.00 purchase. For this example, the user can make two refunds, each of $6.00. If these two refunds have different requestId values (and the same captureRequestId) they must be treated as separate refunds on the same transaction. In this case the user would have $0 left on the transaction once these refunds are complete.