Reversal vs Refund vs Credit | Payment Processor Overview

Overview

This documentation has covered reversal, refund, and credit transactions from the merchant API perspective. While the examples and flows focus on PayConex, there are important processor-specific edge cases that occur behind the scenes.

This includes various settlement scenarios based on the payment processor - particularly when it comes to SALE OR CAPTURE transactions.

Processor-level handling becomes critical when comparing gateway API activity against processor reports. A merchant or ISV may submit a refund through the gateway API, but that transaction may appear as a refund, reversal, credit, or another processor-specific transaction type in downstream processor reporting.

Reversal

A reversal is used to cancel a previous authorization before it is completed by capture.

In this gateway, reversals are only valid for authorization transactions. In other words, a reversal applies to the authorization side of an auth and capture flow. It is used when the merchant has authorized funds but no longer wants to proceed with the capture.

A reversal should not be used by merchants to undo a SALE or a CAPTURE. If the original transaction was a sale or a captured authorization, the merchant should use a refund instead.

Refund

A refund is used to undo a SALE or CAPTURE transaction.

For merchants processing sales, the safe rule is: If you need to undo a sale transaction, use a refund.

This applies whether or not the original transaction has already settled. If the original transaction has not yet been settled, the gateway may convert the refund into a reversal behind the scenes where supported by the processor. Depending on the processor, the gateway may also convert the refund into an unreferenced credit.

From the merchant's perspective, the important distinction is that refunds are the correct API operation for undoing sales and captures. The gateway will determine the appropriate processor-level operation based on the original transaction state, processor capabilities, and gateway configuration.

Credit

A credit is used to send funds from the merchant to the cardholder without referencing a specific original transaction.

Unlike a refund, a credit is a standalone transaction. It is not tied to a previous sale or capture processed through the gateway. This can be useful when the merchant needs to return funds independently of an original gateway transaction.

Credits are disabled by default. A merchant must receive approval from the Bluefin Risk team before credits can be enabled.

For processors that use daily settlement files, credits are usually submitted as independent financial transactions and may appear in a daily settlement file separately from any original sale.

📘 Payment Processors and Transaction Types

Some payment processors interpret captured authorization transaction as completed transaction.

It is important to note that these two terminologies can be interchangeable across different payment processor.

However, for some payment processors, a completed transaction can also mean a settled transaction.

For authorization (auth) transaction, the transaction can be either pending or authorized.

Always make sure to check your specific processor's documentation or test in their sandbox. Bluefin features a sandbox environment as certification environment.

For these test scenarios based on the payment processor, refer to Test Accounts, Cards, and Cases.

As far as the PayConex API, we list the following as transaction types: