Alerts and network programs
RDR and VAMP: Verify Exclusion Treatment With Your Acquirer
A resolved RDR event is not, by itself, proof that the event received the expected VAMP exclusion in the relevant reporting period. Confirm the eligible resolution, its timing and the treatment in the acquirer's authoritative program record. Keep that verification separate from Shopify's own account-health reporting.
The merchant should be able to connect three pieces of evidence: the RDR event, the provider's explanation of applicable treatment and the resulting program data. A green status in an operational inbox establishes only part of that chain.
Start with the published exclusion condition
Visa's VAMP fact sheet identifies exclusions for qualifying pre-dispute resolutions and makes their application contingent on data-extract timing. That timing qualification matters when a merchant expects an immediate change in a report.
Ask the acquirer to confirm the current rule for the named account, region and reporting period. Do not assume that an older product explanation establishes every present reporting detail.
Also identify which component you are asking about. A dispute event, a fraud report and another record associated with the same payment can have different program treatment. A general statement that “RDR excludes it” is too vague unless the provider identifies the relevant record.
Gather the event evidence before requesting a correction
| Evidence item | What it establishes |
|---|---|
| Merchant and acquiring references | The account to which the event belongs |
| Original payment reference | The transaction being discussed |
| RDR case reference | The specific resolution event |
| Resolution outcome and timestamp | What occurred and when |
| Provider acknowledgment | That the outcome was accepted through the approved route |
| Program period and report reference | Where the expected treatment should appear |
Use references through the provider's secure channel rather than attaching unnecessary customer details. The acquirer needs enough information to trace the event, not a complete merchant evidence package.
Keep the operational resolution record intact while the reporting question is investigated. A discrepancy does not justify rewriting the case history to match the result you expected.
Ask how the event reaches the program report
Stripe's monitoring-program guidance distinguishes provider estimates from network data. Ask your own acquirer which view is authoritative and what timing separates its operational records from the relevant network extract.
A useful request is: “Please confirm whether this acknowledged RDR resolution qualifies for exclusion in this program period, which reported component is affected and whether the relevant extract already reflects it. If it does not, please identify the reason and the supported correction process.”
This wording avoids assuming that every difference is an error. The cause might be timing, account scope, an ineligible event or a record mismatch. Each requires a different response.
Ask whether the provider can supply a record-level confirmation or only an aggregate reconciliation. If only aggregate data is available, record that limitation and the evidence supporting the aggregate explanation.
Work through a hypothetical timing difference
Suppose a hypothetical merchant sees an RDR case marked resolved late in a month. Its first program report still appears to include an event associated with the payment. The owner assumes the service failed.
The merchant sends the acquirer the case reference, accepted outcome and timestamps. The acquirer explains which extract produced the report and confirms whether the event was eligible and available before that extract. The merchant then records the explanation or follows the approved correction route.
If the event was not eligible, the merchant should not remove it from its own reconciliation to create the expected total. If the issue was a mapping error, the provider can identify the supported correction evidence. If timing explains it, the merchant checks the relevant later record without promising an automatic result in advance.
The example illustrates a verification method, not an assurance that every late resolution will be excluded in the following month.
Keep Shopify account health distinct
Shopify describes its own chargeback monitoring and account-health treatment. Do not assume a Visa program exclusion removes an event from Shopify's network-resolution-inclusive view or every processor risk assessment.
A merchant can therefore have a resolved RDR event, a confirmed VAMP treatment and a different Shopify operational count without the three records being logically inconsistent. The definitions and periods must be compared before deciding.
Use separate fields in your verification note: operational resolution, financial confirmation and program reporting treatment. This makes it harder for a later reviewer to turn one confirmed fact into three unsupported conclusions.
Close the check with evidence
Finish with a dated result: confirmed exclusion for the specified record and period, confirmed non-exclusion with reason, pending extract, or unresolved discrepancy. Name the provider contact and the next check where one is needed.
Do not promise monitoring-program exit based on a single event or software purchase. The acquirer determines the applicable reporting and program requirements for the full account population.
The reliable standard is a traceable connection between the resolution and the authoritative report. Once that connection is established, the merchant can describe RDR's treatment accurately without confusing a case outcome with a universal reduction in monitoring exposure.
Review RDR's access path and monitor case status while your acquirer confirms program reporting.
Related reading in this collection:
- Can Your Shopify Merchant Account Enroll in Verifi RDR?
- Ethoca Alert Feedback: Confirm What the Provider Treats as Resolved
- Verifi CDRN: Verify the Response Window and Service Commitment