BeyondWallsPay — Vendor API Outlook

Why This Document Exists

The payment architecture for BeyondWallsPay was designed from the very beginning of this engagement with a clear understanding of how the correctional payment landscape works. The Stripe Treasury + Issuing structure, the agent-of-MSB compliance model, and the phased approach to facility relationships — all of this was built into the platform from Day 1 for specific reasons that this document now lays out in full detail.

As we have gone deeper into this build — across hundreds of hours of research, vendor analysis, regulatory review, and market mapping — we have found alternate paths that strengthen the original strategy and accelerate the timeline. The county-level aggregator approach, the AISCO citation dominance engine, and the preferred provider referral model are all evolutions that emerged from the depth of research this engagement has produced. None of them contradict the original architecture. They enhance it.

This document consolidates everything we know about the correctional payment vendor landscape into one place. Every vendor API partner in this space was researched. Every terms of service was reviewed. Every card network registry was checked. Every partner directory was verified. This was compiled across five frontier AI models utilizing Pulse, direct source verification against CFPB enforcement records, Visa and Mastercard card network rules, federal and state regulatory requirements, and investigative industry reporting — supported by nearly three decades of direct experience in the payments and software infrastructure industry.

The purpose is straightforward: to document exactly what is required to process payments in correctional facilities, which vendors control the market, what access they do and do not grant, and why the phased approach this platform follows is the correct path forward. There are no shortcuts in this market. But there are smarter paths — and the research has uncovered several that get BeyondWallsPay where it needs to go faster and with less risk than any alternative approach.

Why the PayFac Model Alone Does Not Solve Correctional Payments

Even if a fully legitimate, registered, PCI-compliant, card-network-approved Payment Facilitator were engaged — a PayFac registration by itself does not grant the ability to process correctional facility payments. The missing piece is always the same: money transmitter licensing, government procurement contracts, and specialized compliance infrastructure that sit entirely outside the PayFac framework. A PayFac with its own MTLs in every state, a sponsor bank willing to underwrite the correctional vertical, and direct government contracts with individual facilities could theoretically operate in this space — but that entity would no longer be functioning as a standard PayFac. It would be a fully licensed correctional payment processor, which is a fundamentally different business requiring years of investment and tens of millions in capital. Here is why:

1. Correctional Payments Require Money Transmitter Licenses, Not Merchant Accounts

Moving funds into an inmate trust or commissary account is a money transmission activity under federal and state law. The companies that dominate this space — JPay (Securus/Aventiv), ViaPath (GTL), and Access Corrections — all hold money transmitter licenses in every state where they operate. A standard PayFac aggregates sub-merchants under merchant processing agreements. It does not hold MTLs. Without MTLs, a PayFac cannot legally transmit funds to inmate accounts. Period.

2. Correctional Facilities Require Government Procurement Contracts

A PayFac onboards sub-merchants through standard merchant agreements. Correctional facilities — whether state DOCs, county jails, or federal BOP — procure services through government RFP/RFQ processes, formal procurement contracts, and inter-agency agreements. These are fundamentally different legal instruments than a PayFac sub-merchant agreement. Every major correctional payment provider enters into formal government contracts with each individual facility it serves.

3. The Sponsor Bank Will Not Approve It

A PayFac operates under a sponsoring acquiring bank that bears ultimate liability for the PayFac's entire sub-merchant portfolio. Correctional facility payments combine government contracting requirements, money transmission obligations, heightened BSA/AML risk, complex chargeback scenarios (inmate transfers, account closures, restitution holds), and significant reputational exposure. No standard acquiring bank sponsoring a PayFac for retail or home services would extend that sponsorship to correctional facility payment processing without a fundamentally different risk assessment, capitalization requirement, and compliance framework. The sponsor bank's own MTL obligations come into play — if the bank doesn't hold the corresponding MTLs for correctional money transmission, the PayFac can't operate in those states regardless of its own registration status.

4. Card Network Rules Require Enhanced Due Diligence

Visa's Integrity Risk Program (VIRP) and Mastercard's compliance frameworks impose tiered scrutiny on high-risk and government-adjacent merchant categories. Government services, money transmission, and fund transfers to third-party accounts all trigger enhanced requirements. A PayFac's sponsoring bank would need to approve each correctional facility sub-merchant individually, requiring the PayFac to demonstrate compliance infrastructure for correctional-specific risks — including BSA/AML monitoring, OFAC screening, and restitution hold processing.

5. BSA/AML Obligations Are Heightened in Correctional Contexts

The movement of funds through inmate accounts carries elevated money laundering risk. Correctional payment providers must maintain robust suspicious activity monitoring and SAR filing capabilities specifically calibrated to detect patterns of illicit fund movement through inmate accounts. This requires specialized compliance infrastructure, trained personnel, and direct relationships with facility security teams. Standard PayFacs do not build or maintain this capability.

6. Stripe Itself Restricts Government Services and Bail Bonds

Stripe's Prohibited and Restricted Businesses list includes "No-value-added services, including the sale or resale of a service without added benefit to the buyer and resale of government offerings without authorisation or added value." Stripe also specifically prohibits bail bond services. Any PayFac claiming to use Stripe as its payment processor would face Stripe's own restricted categories for correctional facility payment processing without explicit prior approval — approval that would require demonstrating licensing and compliance infrastructure that no standard PayFac maintains.

What a Legitimate PayFac Is Required to Have

For reference, the following is what any company operating as a Payment Facilitator in the United States in 2026 must have under Visa, Mastercard, federal, and state requirements:

Becoming a registered PayFac typically requires $500,000–$5,000,000 in upfront capital, 12–18 months of preparation, Visa and Mastercard registration fees of approximately $75,000–$100,000 per network annually, a sponsoring acquiring bank relationship, and Level 1 PCI DSS certification. There are only approximately 248 registered PayFacs in all of North America on Mastercard's list. Adding correctional-specific capabilities (MTLs, government procurement, BSA/AML for inmate accounts, restitution processing) adds 12+ additional months and significant capital requirements on top of that.

The Complete Vendor Landscape — ~35 Companies Across 3,100+ County Jails

Across the entire U.S. county jail market (~3,100 facilities per Bureau of Justice Statistics / American Jail Association), there are approximately 25–35 distinct vendors operating payment portals, commissary deposits, or related inmate financial services. The vast majority of contracts are held by 4–5 companies through bundled exclusive deals. A PayFac structure does not solve a single one of these vendor relationships — it only creates the ability to collect money from families, which Stripe already does.

Tier 1 — The Big Bundlers (Phone + Payment + Commissary + Everything)

These companies dominate because they bundle phone, tablets, video, messaging, money transfers, commissary, and banking into a single exclusive contract. Facilities sign one deal and get locked in for 5–10 years. Together, GTL/ViaPath and Securus/JPay control approximately 80% of the market and have been documented offering signing bonuses as large as $1.5 million for 7-year exclusive contracts.

A PayFac does not unlock any of these. These companies own the facility relationship through multi-year exclusive contracts with signing bonuses. They will not grant API access to a third party because doing so would cannibalize their own payment revenue. A PayFac gives you the ability to collect money — it does NOT give you the ability to deposit it through any of these systems.

Tier 2 — Mid-Size Regional Payment / Commissary Specialists

These companies have carved out county-by-county contracts in specific regions. They are the most fragmented part of the market and the most realistic targets for BWP's Phase 2 direct replacement strategy.

Tier 3 — Small / Niche / Single-Service Operators

Thin deposit-only portals, care package vendors, and micro-regional players. Many serve only a handful of counties.

The Only Open Rail

Western Union and MoneyGram are money transfer rails, not correctional payment portals. They don't hold exclusive facility contracts. They operate supplementally — families can use them where accepted, but they are not the primary contracted vendor running the portal. WU's most structured relationship is with Federal BOP, not county jails.

API & Partner Directory Audit — Every Vendor Checked

Each vendor's website was reviewed for any public-facing API documentation, developer program, partner directory, integration marketplace, or third-party payment access of any kind. The results confirm what the industry structure predicts: these companies do not share their payment rails with anyone.

Thirteen correctional payment vendors were audited. Zero have a public API. Zero have a developer program. Zero have a payment partner directory. Zero offer any form of third-party payment integration. The only vendor with any API infrastructure at all is Western Union, and that is an enterprise-level business development conversation — not a self-serve integration. Every other vendor in this market builds, owns, and operates their entire technology stack in-house with zero external access by design.

This is not an oversight. This is the business model. These companies pay millions for exclusive facility contracts specifically so they can control the entire payment experience. Opening an API would let competitors access the revenue stream they paid to monopolize. This access is not granted through standard business development channels. The only way in is to either drive enough volume through their public portals that a partnership becomes attractive to them — or bypass them entirely by signing facilities directly.

Research conducted June 2026 across five frontier AI models utilizing Pulse, with direct verification against each vendor's corporate website, App Store/Play Store listings, CBInsights profiles, press releases, and public documentation. ViaPath partnerships verified against viapath.com/media-center press releases. Securus One capabilities verified against Aventiv ACA Conference announcement (Aug 2025). Keefe in-house development statement sourced from keefegroup.com/companies/keefe-commissary-network.

Detailed Vendor Profiles — The Big Three

The following profiles document the three companies that control the vast majority of correctional payment processing in the United States. Each includes corporate structure, regulatory history, contact information, and — critically — the reality of third-party API access.

Smaller Players

The Reality: Why "Just Connect" Doesn't Work

Here is what that statement ignores:

Problem 1: PayFac Doesn't Open the Vendor Door

A PayFac (Payment Facilitator) structure lets you collect money from families. But that was never the hard part — Stripe already does that. The hard part is getting money INTO the inmate's commissary account through the facility's contracted vendor. A PayFac registration does absolutely nothing to open AccessCorrections, JPay, or TouchPay. Those are closed systems with exclusive facility contracts. You still can't deposit. You still can't connect. The PayFac solves the wrong side of the equation.

Problem 2: Underwriting and Background Checks

A PayFac's sponsor bank runs deep background checks on every control person — officers, directors, beneficial owners, anyone with authority over the money flow. The underwriting requirements are extensive and non-negotiable. For any company where the control group presents complexity in standard financial services background screening, the PayFac path presents significant underwriting challenges that may not be resolvable within the timelines typically quoted by outside parties. These are questions that should be addressed before any commitment of time or resources.

Problem 3: Vendor API Access — $50K+ Per Vendor With No Guarantee

Even if a PayFac were established, you would still need to connect to each vendor's payment system individually. Based on our research:

Problem 4: The Good Old Boys Club

This industry has been controlled by the same companies for decades. ViaPath (GTL) has been operating since 1989 — 37 years. Keefe Group since 1975 — 50 years. Securus since 1986 — 40 years. These companies have multi-year exclusive contracts with every facility they serve. They pay commissions to facilities to maintain those contracts. They bundle services (phone + tablets + deposits + commissary + surveillance) to make switching costly. They are backed by private equity firms (American Securities, Platinum Equity, H.I.G. Capital) that invest specifically because the monopoly structure guarantees revenue.

Access to this market is earned through years of compliance investment, facility relationships, and licensing — not through a 90-day onboarding process.

Problem 5: Regulatory Exposure

The CFPB fined ViaPath/GTL $3M in November 2024 for unfair practices. JPay was fined $6M for release-card abuses. These companies are under active federal regulatory scrutiny. Any company that ties itself to their payment infrastructure inherits that regulatory risk. A PayFac sitting on top of vendors already under CFPB enforcement orders is adding compliance exposure, not reducing it.

How BeyondWallsPay Actually Solves This

After conducting this research across five frontier AI models, direct source verification, and extensive industry analysis through our Pulse infrastructure, the architecture was designed around one principle: do not enter the payments stack until you have the leverage to bypass the vendors entirely.

Phase 1: The Aggregator (July 2026 — Months 1–12)

BWP connects to 349 county jails across 11 states, expanding to 3,100+ nationally by December 2026. For each facility, BWP identifies the active payment vendor, captures the facility code, deposit URL, and accepted methods, and routes the family directly to that vendor's public portal with the inmate's booking information pre-filled.

BWP does not hold funds. BWP does not touch the vendor's system. BWP is the front door — the system families use to find their loved one, see how to send money, find a bail bondsman, and get status alerts. A nominal entry fee provides access to gated features including payment routing, status alerts, bail bond matching, and attorney referrals — while the payment transaction itself is completed directly on the vendor's platform. Zero PCI. Zero MTL. Zero PayFac. Zero compliance surface area. The pricing model is flexible — what is not flexible is the revenue architecture underneath it.

This analysis does not come from a development perspective. It comes from nearly three decades in payments and capital generation. The development capability was born out of necessity over the last five years — because the people being paid to build kept failing to deliver. The lens applied here is the same lens that has always driven this engagement: how does this platform generate capital, and what is the fastest, lowest-risk path to get there? The answer has been in front of this project the entire time — not only in the payment architecture, but in the alternate revenue methods this research has surfaced. There are multiple ways to generate meaningful revenue from this platform. At even a conservative conversion rate, the numbers are substantial. The methodology is sound. The infrastructure is built. The paths are documented. The only remaining variable is execution.

During Phase 1, BWP simultaneously launches AISCO — the AI citation dominance engine that places BeyondWallsPay as the #1 cited platform across all five frontier AI models for every query related to jail payments, inmate location, and bail. Within 90 days, any family member asking any AI tool how to send money to an inmate gets pointed to BWP. This builds the brand recognition and user base that makes Phase 2 possible.

Phase 2: Direct Facility Relationships (December 2026 — Months 6–12)

With AISCO dominance established and a national user base active, BWP begins direct outreach to county jail administrators. The pitch sells itself: "Type your facility name into ChatGPT. We're #1." BWP offers facilities a superior platform — better family experience, lower fees, real-time reporting — and signs direct contracts that replace TouchPay, JailATM, and Access Corrections as the facility's payment vendor.

This is the only way to bypass the oligopoly. You don't ask for API access. You don't connect through a PayFac. You replace them at the facility level, one county at a time. And you can do this because you have the brand (AISCO), the user base (Phase 1), and the contact database (349 jail administrators with names, phones, and emails already catalogued).

Phase 3: Stripe Treasury + Issuing — The Payment Engine (July 2027+)

Once direct facility contracts are in place, BWP activates the Stripe Treasury + Issuing architecture to process deposits directly:

Why this works and PayFac doesn't:

The Bottom Line

This research was not conducted casually. Five frontier AI models were deployed in parallel alongside our Pulse research infrastructure to verify every claim, cross-reference every source, and pressure-test every assumption. The CFPB enforcement orders are public record. The exclusive contract structures are documented in federal court filings and investigative journalism. The vendor websites explicitly describe their closed-ecosystem models. The App Store listings identify the developers. The private equity ownership is on record.

A 90-day PayFac timeline does not account for the structural realities of this market. The barrier is not technology — it is regulatory architecture, exclusive contracts, and decades of entrenched vendor relationships. The path forward is to build your own position of strength, bring 14.75 million family members to the platform through AISCO, and then approach county jails with more brand authority than any vendor in this document.

That is the BWP methodology. That is what is being built. And that is why Phase 1 (aggregator + AISCO dominance) comes before Phase 3 (direct payments). You earn the right to process payments by becoming the name every family in America knows first.

The Low-Hanging Fruit Is Already Mapped

While the major vendors have their systems locked down, there are a significant number of county jails — particularly smaller and rural facilities — that are still operating on static PDF rosters with no real payment vendor at all. No TouchPay. No JailATM. No Access Corrections. These facilities accept money orders at the front desk or have a basic county-built website with no integrated payment system.

We have already identified and catalogued these facilities. They are documented in the county jail census and adapter analysis delivered earlier in this engagement. These jails represent the easiest direct-connect targets for BWP — facilities where you can integrate your payment system directly with minimal friction, no vendor displacement, and next to no cost. They have no exclusive contracts blocking the door because nobody is serving them. They are waiting for exactly what BWP offers.

This is one of many examples of why it is important to read the documents this engagement produces. Each one is built with purpose. Each one identifies what is possible, what is not possible, where you can go, why you can go there, and where you should not go. The research, the census data, the adapter classifications, the vendor analysis, the regulatory review — it is all interconnected. One document feeds the next. The answers to most questions are already written down.

That said — the door is always open to ask. If there is an idea, a potential path, a "what if" — bring it to us. That is what the majority of our clients do. They ask what is possible, and we find a way to make it possible. We have done this across dozens of engagements and nearly three decades of building infrastructure in regulated industries. If you can dream it, we can build it. We just have to build it within regulation and within the scope of the law. And within those boundaries, there is far more room than most people realize.

Terms of Service Audit — Automated Access Prohibitions by Vendor

Each vendor's published Terms of Service was reviewed for language prohibiting automated agents, bots, headless browsers, scrapers, or any non-human interaction with their platforms. The results confirm that automated payment execution against these portals is explicitly prohibited by the vendors themselves — separate from and in addition to federal law.

The distinction matters. Reading a vendor's public-facing website to identify which payment portal a facility uses — and then routing a family member to that portal via a standard link — is normal web usage. No TOS is violated. No automation touches their system. The family member interacts with the vendor portal as a human, through a browser, exactly as intended.

Sending an automated agent, headless browser, or bot to fill out forms, submit payment information, and execute transactions on a vendor's platform without authorization is a different activity entirely. It is prohibited by every vendor's Terms of Service, it potentially violates the CFAA (18 U.S.C. § 1030), and at least one major vendor (Securus/JPay) explicitly states in writing that they will refer such violations to law enforcement for criminal investigation.

This is the line. Phase 1 stays on the right side of it. The phased approach was designed specifically so that BWP never needs to cross it.