Alerts and network programs

RDR Credits and Shopify Refunds: Confirm the Money Movement Before Acting

Coins spread out pile.
Photo: Shopify Partners / Burst

Before issuing a Shopify refund for an RDR-related case, confirm whether the approved resolution process has already returned money to the cardholder. An RDR credit and a merchant-created Shopify refund are different events. Treating them as interchangeable can produce an unnecessary second payment.

The correct first step is to identify the actual financial route used by your processor or RDR provider and reconcile the specific transaction. A status label that says “resolved” is useful, but it does not by itself explain where the money moved or how it appears in Shopify.

Ask the provider to describe the credit route

Verifi's RDR description identifies automated cardholder resolution. The merchant still needs its own provider to explain the resulting ledger entries, transaction references and settlement behavior.

Request a sample completed event showing the original payment reference, RDR case reference, resolution amount, currency and financial acknowledgment. Ask whether the credit travels through the network resolution process, a processor mechanism or another approved route in your arrangement.

Do not assume that the Shopify order's refund history will represent every external or network event in the same way. Your provider should identify the authoritative place to verify completion and the reference that links it to the original payment.

Also ask how partial amounts, failed credits or later adjustments are represented. An apparently simple full-resolution example does not establish the behavior of every case your store may receive.

Separate the three records you need

Record Question it answers What it does not prove alone
RDR event record Which case was accepted or resolved? Final posting in every ledger
Processor financial record Which debit, credit or adjustment occurred? Meaning of every Shopify order label
Shopify order payment record What Shopify shows for the order's payment activity Absence of external money movement

The aim is not to force all three systems to use the same words. It is to establish a reliable link between the records and understand any timing difference.

Save the source references and the time checked. A support agent reading a customer message later should be able to see that a prior resolution was investigated before deciding on another financial action.

Keep case state, credit state and reconciliation state as separate internal observations. “RDR resolved; financial posting confirmed; Shopify representation checked” is clearer than one overloaded “refunded” label.

Work through a hypothetical double-credit risk

Imagine a hypothetical $80 order receives an RDR resolution event. A customer later asks the store for a refund, and an operator sees no familiar refund entry on the Shopify order.

If the operator immediately creates another payment, the customer may receive a second credit. The correct review is to locate the RDR event's original payment reference and ask the provider's financial records whether the $80 resolution has posted or is in progress.

Suppose the provider confirms the network credit and supplies its reference. The merchant records that evidence and follows the provider's guidance for any remaining display discrepancy. It does not create another refund merely to make the Shopify screen look familiar.

Now change the hypothetical: the event is only received, with no completed resolution or financial acknowledgment. The merchant should not tell the customer a credit is complete. It escalates the specific state through the approved provider route and determines the appropriate next action from verified records.

Both branches depend on evidence of money movement, not on an assumption that every RDR-related status means the same thing.

Keep reporting treatment separate

Stripe's monitoring-program guidance distinguishes network program calculations from ordinary case outcomes. Shopify also describes its own chargeback monitoring, including network-resolution treatment for account health.

Do not translate “RDR resolved” into “removed from every chargeback measure.” Visa VAMP treatment, processor account-health reporting and a merchant's own operational view can use different populations and timing.

For this financial check, record only what you have established: the event, amount, currency and confirmed credit route. Ask the acquirer separately how the event is treated in the relevant program period. A money-movement reconciliation should not quietly become an unsupported reporting promise.

The same restraint applies to customer communication. Describe the verified credit status and provider reference available to your team, without promising a bank posting date that the source has not confirmed.

Establish a safe merchant decision checkpoint

Before another refund is considered, require the operator to identify the original payment, inspect prior credits and obtain the authoritative status of the RDR resolution. If records conflict, assign the discrepancy to a named owner and preserve the source evidence.

This is not a reason to delay legitimate customer resolution indefinitely. It is a way to choose the correct action with knowledge of what has already happened. Escalate urgent uncertainty through the provider's supported channel.

Document the provider-specific route once and validate it when the acquiring arrangement changes. The team then has a concrete answer to the recurring question: where do we look to confirm an RDR credit before moving money again?

Inspect Verifi's workflow requirements and Lower Chargeback's action boundaries.

Review action boundaries

Related reading in this collection: