Refund Payment

Sequence Diagram

Why Refund Payment is Important

Occasionally customers may choose to return a product or a merchant may decide to issue a refund, for example due to minor damage or delayed delivery. The Refund Payment call manages these situations. The merchant may also choose to trigger the Refund call through the Merchant Portal.

An Example

Astrid has received her hat and jacket via two deliveries (the socks were voided by the merchant), but has decided that the woolen hat she ordered is a different color than she expected. She uses the original packaging to send just the woolen hat back to the merchant. Then, she goes to my.riverty.com and uses the “Report a Return” feature, triggering a notification to the merchant to expect a return of the woolen hat.

The merchant receives the woolen hat, sees that it is in good condition and still has the tags attached. The refund is accepted, and the merchant issues a REFUND call from their webshop to the Riverty eComm API. Astrid’s invoice is updated and the cost of the woolen hat is deducted from the total. She now only has to pay for the sock and the jacket she decided to keep.

This is a POST call to the REFUND endpoint of the Riverty eCommerce API. Embedded in the URL is the Order.Number from the AUTHORIZE and CAPTURES calls.

Return costs

Merchants have the ability to charge customers a fee associated to the return process. This fee can be charged by adding a separate item within the Refund API for the return costs using a negative grossUnitPrice value. An example can be found below. Return costs are clearly displayed on the customer invoice for transparency purposes.

Its not recommended to charge return costs by deducting the return costs from the original Unitprice amount within the Refund API. Doing so negatively impacts the customer experience.

Note, that all fee’s and possible additional charges towards customers need to be clearly mentioned and explained during the checkout process.

API Call Blocks:

Capture Number

This is the unique ID that was provided in the response to the CAPTURES call. This tells Riverty where to debit the money (from the merchant’s settlement account, and the specific transaction) that will be credited to the customer.

Order Items

This contains the same information as the AUTHORIZE (and/or CAPTURES) call, for the product(s) being refunded.

In this example, we are doing a Partial Refund – refunding only one order item out of many.

If we send the POST call to the REFUND endpoint with nothing in the body, we will be making a Full Refund – refunding all order items.

You can do multiple Partial Refunds within the same order. You can also do a Full Refund after a Partial Refund – refunding all items that were not refunded before.