Updated July 20th, 2021
Refund authorizations, sometimes referred to as "online refunds" or "purchase return authorizations," serve the same purpose as purchase or sale authorizations; they verify that the payment account is valid and capable of completing the transaction. This guide describes updates to the CardPointe Gateway to support refund authorizations, and the minor changes you should expect to see when you issue refunds.
See the following card brand guidelines for detailed information, requirements, and recommendations:
The changes described in this document are currently in development for First Data/Fiserv Processing platforms. Additional details will be available once development completes.
You should plan to update and test your application as soon as possible. See Integrated Payment Application Changes, below, for more information.
Understanding Refund Authorizations
When you initiate a payment, the CardPointe Gateway connects to the issuing payment card network to authorize the cardholder's account and the amount of the transaction. If the authorization is successful, the transaction is completed and returns an approval response. If the authorization is declined for any reason, the transaction is not completed, and returns a declined response, usually with a description of the reason for the decline.
Previously, refunds were not subject to the same authorization process; instead, the CardPointe Gateway would automatically approve and process refunds. With the changes to comply with the issuer mandates, the CardPointe Gateway will now authorize refund transactions in real time, increasing consistency in the merchant and cardholder payment experience, and preventing fraudulent refunds.
Note the following important considerations, which may impact your business and integrated application (for CardPointe Gateway API users):
- You may now experience refund declines in some cases, for example:
- The supplied card is closed or frozen
- The supplied payment method does not support refunds (for example, a gift card)
- Your application will receive different refund response data values from the CardPointe Gateway. See Integrated Payment Application Changes, below for detailed information.
As a merchant, you reserve the right to establish refund and return policies that suit your business and customer needs; however, it is a best-practice to periodically review your policies in the context of industry trends and card brand requirements.
Integrated Payment Application Changes
Depending on how your application handles payment and refund transaction responses, you may need to make minor changes to handle the updated refund authorization responses returned by the CardPointe Gateway.
Whereas the CardPointe Gateway would previously return the same successful authorization response for every refund, the response will now include real-time authorization and status details from the issuer and processor.
The following table describes the response changes in detail.
|Field Name||Previous Value||New Value|
|A unique, alpha-numeric authorization code, returned by the issuer.|
|A 2 or 3 character response status code, returned by the processor.|
See the Gateway Response Codes Guide for a complete list of all response codes.
|A 3 or 4 character abbreviation for the processor name. |
Currently the following values are supported:
FNOR - First Data North
RPCT - First Data Rapid Connect
|A one-character response status-indicator, returned by the processor.|
One of the following values:
A - typically returned for approved authorizations.
B - typically returned in the event of a system error.
C - typically returned for declined authorizations.
|A text description of the authorization status, returned by the processor. |
See the Gateway Response Codes Guide for a complete list of all response status descriptions and corresponding indicators.
Testing Refund Authorizations and Declines
The CardPointe Gateway UAT environment now supports refund decline emulation for First Data North, First Data Rapid Connect, and Chase Paymentech (PMT) merchants. Similarly to testing specific authorization response scenarios, using amount-driven responses, you can test individual refund response codes, by sending a partial refund request using an amount value that includes the desired response code.
Like in Production, UAT transactions cannot be refunded until they have settled, unless the MID is enabled to refund unsettled transactions.
To test a refund decline, do the following:
- Run an authorization request including
"amount":"2000.00" or greater.
- Run a refund request including the
retref from the authorization response and
nnn is the 2 (including leading 0) or 3-digit decline response code you want to receive.
For example, to return a RPCT 500 "Decline" response, include
"amount":"1500.00" in the refund request.
See Processing Host Response Codes for a list of possible response codes by processor.
See Testing With Amount-Driven Response Codes in the Testing Your Integration guide for additional information and examples.
CardPointe Payment Application Changes
No changes are required to the CardPointe Virtual Terminal or CardPointe Hosted Payment Page; however, as a result of the updates to CardPointe Gateway refund processing, you may experience refund declines, and will see a change in the response information returned for refund transactions, as described in Integrated Payment Application Changes.
This feature is still in development, and additional details will be available once development completes.