9 September 2026. The public implementation counterpart establishes a substantial onward effect: Stripe generally declines MATCH-listed merchants while reserving consideration for documented exceptional circumstances. This is evidence of one provider's published practice. It does not establish a Mastercard rule that every provider must reject every listed business, or loss of access to all banking.
Source, version and reading scope
[Stripe, Terminated merchant files](http[local research file] also labelled High risk merchant lists in its navigation. Original HTML retained as acquirer-stripe-match.html, SHA256 b867b5801678b18afc54e0a9b0ea684ca788ac70132239ff19cb97f6979773c7; HTTP 200, 825,132 bytes, captured 2026-09-09 at 17:12:10 UTC. No revision or effective date was displayed in the substantive text. This is an observed current-page account, not a dated historic policy. The locale is English (United Kingdom), but the captured country selector reads United States; it does not identify a UK acquiring-bank contract.
The complete substantive original text was read, including the separate Visa section to identify the boundary. The operative MATCH scope is acquirer-stripe-match.html.derived.txt lines 88–170; the Visa section is not adopted into the MATCH findings. The primary web reader independently exposed the same text, lines 10–80 in reference turn1482view0. The original HTML is the retained source, and the parsed text is a derivative, not a second publication.
Decisive provisions
| Locator in the retained text | Scoped finding |
|---|---|
| Opening, lines 88–89; qualification, 92–93 | Stripe describes preapproval database screening and qualifying-termination reporting as acquirer duties. Its broader assertion that most processors reject listings is an attributed industry claim, not an independently established frequency. |
| Information added, 149–162 | The described record includes business and principal-owner identifiers, dates and reason code. Stripe says it does not disclose database information to users. This run obtained no actual merchant record. |
| Entry removal, 163–168 | Stripe describes removal for erroneous entry or cured PCI noncompliance, through the listing acquirer; it directs merchants unable to identify that acquirer to Mastercard. Its general retention summary is five years. These are Stripe's summaries, subject to the current network instrument. |
| Processing limitations, 169–170 | A listing generally disqualifies Stripe processing. Consideration requires evidence of an exceptional circumstance, with verified identity theft given as an example. This promises consideration, not approval. Resolving excessive-chargeback issues does not by itself permit Stripe to remove the qualifying record. |
The example transaction arithmetic elsewhere on the page is expressly hypothetical. It supplies neither a merchant case nor evidence that a particular referral was acted upon. No quantitative eligibility threshold is independently adopted from this page where the current Mastercard manual is the governing source.
Comparison with the current network instrument
Pinpoint reading of root's shared [Security Rules and Procedures—Merchant Edition, 4 August 2026](http[local research file] sharpens the distinction. Section 11.2, PDF/printed page 148, expressly permits acquirers to onboard listed merchants and payment facilitators to onboard listed sponsored merchants. Stripe's general disqualification is therefore its stated acceptance practice, not an unavoidable consequence of mandatory database use.
The summaries also differ. Section 11.5, page 151, specifies five calendar days under its enumerated termination/awareness triggers, versus Stripe's one working day. Table 11.4, page 157, uses previous-three-month language and a 1.5% threshold for code 04, versus Stripe's monthly 1%; its code 05 period also differs. The manual's awkward period wording is not reconstructed into a new formula here. Section 11.13, pages 155–156, places removal with Mastercard and allows the merchant itself to request removal for cured PCI noncompliance if the acquirer is unwilling or unable, following the stated proof process. That alternative is absent from Stripe's opening acquirer-only summary.
These are source/version mismatches, not proof of when rules changed or that Stripe applied the wrong rule in any case. The dated network instrument controls the network-rule description; Stripe remains the primary account of its own published acceptance practice. No additional provider was acquired to manufacture agreement.
The source is a primary-reader rendition with no original PDF retained. Independently inspected relevant reader passages in the shared rules-chapter11.reader.txt and rules-chapter11-gaps.reader.txt, and pinpoint working-reader references turn1493view1 and turn1494view0: section 11.2 final paragraph; sections 11.5 and 11.6; section 11.10; section 11.13; and table 11.4 codes 04–05. This is not a claim to have read the whole manual or independently rendered its pages. Root owns full Chapter 11 review and lifecycle synthesis.
Connection to the earlier policy
Reused, without reacquisition, the [Mastercard Anti-Piracy Policy](http[local research file] sections 1–2, retained in ../wipo-payment-wave-2026-09-09/participant-policies.reader.txt, reader lines 161–179. It separately requires investigation and cessation of payment acceptance for a qualifying infringing product, then conditionally requires applicable MATCH listing if the acquirer terminates the merchant. That source remains a retained primary-reader derivative; its ordinary original GET previously failed with 403 and remains closed.
The supported relationship chain is therefore conditional: an applicable termination can generate a shared record; screening exposes the record to later underwriting; Stripe's stated acceptance policy gives that record a further restrictive consequence. This does not prove an ALERT-PAY-specific route into MATCH, a Stripe listing or decision concerning any identified merchant, or that Stripe itself was the acquiring bank which entered a record. A listing, termination of one processing relationship, denial of a new application, and closure of a deposit account are distinct events.
For integration, useful typed relations are Mastercard MATCH record → Stripe underwriting consideration (provider_published_acceptance_policy), and listing acquirer → merchant record (reported_correction_custodian, qualified by the current Mastercard rules). Do not add WIPO → Stripe, universal bank-denial, or exercised-removal edges from this evidence.
Boundary and next discriminator
No second implementation source was needed. There were no live database queries, account access, merchant data, operational API calls or submitted forms. The current SPME manual is root's separate lane, with the pinpoint comparison above; its ordinary PDF GET failed and a working reader identifies the 4 August 2026 version. No February version date or original-PDF custody is imported here.
The strongest rival to a universal-ban account is differentiated underwriting: the record is shared, but acceptance and exceptional consideration remain provider decisions under the applicable rules. The highest-value missing record is a public, reasoned acquiring or processor decision showing how a MATCH record was assessed, challenged, corrected and reconsidered. A public policy supplies the mechanism; it does not establish its frequency, error rate or a particular customer's restoration. Acquisition closes here for the combined forest review.