AI Payment Compatibility Index

Approval matrix: merchant × card network

Sample sufficiency is a qualitative tier (large / medium / small); tier thresholds and transaction counts are not published. Small-tier cells fluctuate between periods — read them as a trend, not as a single-period figure.

The small Visa sample on the Meta row reflects our own recommendation, not merchant behaviour: for Facebook Ads we primarily point users to Mastercard (more reliable card binding and ad-spend charging).

3DS / AVS observations

Across the period’s full decline-reason records — including the excluded declines, i.e. before any exclusion is applied — none of the merchants above produced a decline attributable to a 3DS verification challenge or an AVS address-check mismatch. Two limitations apply: first, upstream decline reasons carry no dedicated 3DS / AVS category and a small number of declines have unknown causes, so this finding is bounded by that granularity; second, this is an observational finding about this platform’s cards and billing-address configuration — not a general claim that these merchants run no 3DS / AVS checks. Merchant risk policies can change at any time; we re-verify monthly.

Methodology (published in full)

Data source

RDVCC’s real clearing records (all authorization events), aggregated by normalized merchant name. No lab tests; no third-party or industry averages. The extraction query and merchant-normalization rules are archived in our internal repository so every period is reproducible.

Time window

Trailing 30-day window, refreshed monthly and archived as a period (current period: 2026-08).

Definition

Approval rate = (total authorizations − all declines) ÷ (total authorizations − excluded declines). Two groups are excluded. First, user-side causes: insufficient card balance or limit (including limit-exceeded variants), billing-address input errors, mistyped card details (CVV / expiry), and cards not in an active state (mostly frozen by their owners, with a small share frozen by platform risk control). Second, platform policy blocks: transactions stopped by our own restricted-merchant-category (MCC) and risk rules. Neither group reflects the card’s own payment capability at that merchant. Note: when every decline in a cell falls into the exclusions, the cell reads 100% — 100% does not mean no declines occurred in the period.

Residual declines

Every decline outside the exclusions — including transient upstream errors and unknown causes — is counted as-is. No second-pass polishing.

Limitations

Single-platform view (reflects this platform’s cards and configuration only); self-reported data (not independently audited); sample sufficiency expressed as qualitative tiers; this period is not broken down by card product type (dedicated vs shared limit); a few pages on this site carry historical data over longer windows — this page’s definition prevails; merchant risk-policy changes can invalidate past periods, so always rely on the latest period.

Machine-readable data

The matrix on this page is also available in machine-readable form, generated from the same source and updated in lockstep, and likewise carrying no transaction counts (the first CSV line is a “#” metadata comment):

Citation: credit “RDVCC Payments Research” with the period and this page’s URL; do not alter the figures or quote them outside their methodology; past periods do not describe the current state.

Changelog

• 2026-08 (2026-08-31) · Baseline period: first release. Approval matrix across six merchants and two card networks; no 3DS- or AVS-type declines found in the period’s full decline-reason records.