This post is for AP platform product leaders, embedded finance architects, and payments operators building or rebuilding an AP payments capability. It covers the full stack — from bank structure and program model through orchestration platform, payment products, partner selection, AR integration, AI execution, and STP optimization. It is long because the subject requires it.
The architecture problem most AP platforms have
Most AP payment platforms were built in layers — check disbursement first, ACH added later, virtual card bolted on when someone realized it generated revenue, RTP added when clients asked for it. Each layer was built by a different team, connected by different integrations, managed by different vendors. The result is a payments stack that works but doesn't perform: STP rates stuck at 10–20%, monetization below potential, supplier experience fragmented, and operations teams manually processing exceptions that should have been handled automatically.
A high-performing AP payments platform is not a collection of payment methods. It is an integrated architecture: a program model and bank structure that captures maximum economics, an orchestration and decision layer that routes every payment to the optimal path, a payment product stack that covers every supplier scenario, AR partnerships that drive STP rates, and AI execution that makes routing decisions in real time. Every layer depends on the ones below it. Getting any one of them wrong limits the ceiling of the rest.
This post builds the architecture from the foundation up.
Layer 1: Program model and bank structure
Everything in an AP payments platform sits on the program model and bank structure. The bank relationship determines what interchange economics are available, what products are permissible, what compliance standards apply, and what the economics ceiling looks like at scale. Getting this wrong at the foundation means every optimization built on top of it is optimizing within a constrained ceiling.
The right program model for an AP platform at scale. For AP platforms processing $50M+ annual payment volume, the target program model is a direct bank relationship with a commercial card BIN structure — not BaaS middleware. The economics difference is material: BaaS interchange share typically leaves the platform with 60–90 basis points on VCard. A direct bank relationship with a commercial purchasing card BIN captures 150–250 basis points. At $200M annual VCard volume, that difference is $1.8M–$3.8M annually in recoverable economics.
The direct bank relationship also enables: float yield negotiation on FBO balances (3–5% annualized on average daily balance), custom fee structures the BaaS layer doesn't support, and product flexibility — the ability to add payment types, adjust spending controls, and expand the program without a middleware provider's product roadmap constraining the timeline.
Commercial purchasing card BIN selection. Not all virtual card BINs are equal. Consumer card BINs generate 100–130 basis points of interchange. Commercial purchasing card BINs (P-card BINs) generate 175–250 basis points. The BIN is selected at program launch and is architecturally difficult to change — it requires re-issuing card capabilities and potentially re-integrating with the card processor. Select the commercial purchasing card BIN from the start. The interchange difference compounds on every transaction for the life of the program.
FBO account structure for supplier payments. Outbound supplier payments flow from the buyer's FBO account through the payment rail to the supplier. The FBO structure — how buyer payment accounts are structured, how settlement timing affects float, how the bank account hierarchy supports multi-buyer programs — needs to be designed for the program's operating model. A multi-buyer AP platform (serving many corporate buyers) needs an FBO structure that segregates buyer balances cleanly while enabling efficient payment execution across all buyer accounts.
Compliance framework for a commercial AP program. AP platforms serving business buyers have a different compliance profile than consumer-facing programs. BSA/AML for commercial AP focuses on counterparty verification (supplier KYB), sanctions screening on all payees, and monitoring for patterns inconsistent with the buyer's normal payment behavior. The compliance framework should be designed specifically for the commercial B2B payment profile — not adapted from a consumer or fintech compliance template.
Layer 2: The orchestration, ledger, and decision platform
The orchestration and decision platform is the central nervous system of the AP payments stack. It is the layer that receives payment instructions, makes routing decisions, executes against the payment product stack, manages state through the payment lifecycle, and produces the reconciliation records that keep the program clean. Without this layer designed as a coherent system, the payment products beneath it are independent capabilities that don't produce a coherent program.
Payment orchestration architecture. The orchestration layer takes a payment instruction — supplier ID, amount, urgency, buyer preferences — and produces a rail selection decision: which payment product, in which sequence, with what fallback logic. This is the waterfall in operational form. The orchestration layer should be implemented as a dedicated service — not embedded in the AP workflow application — with defined inputs, defined outputs, and observable state at every decision point.
The orchestration service needs: a supplier payment profile registry (what rails each supplier accepts, their STP configuration status, historical acceptance rates by rail and amount range), a payment policy engine (buyer-defined rules — maximum VCard amount, preferred rail by supplier category, urgency overrides), a real-time route evaluator (applying policy and supplier profile to produce a ranked rail sequence), and an execution dispatcher (sending the payment instruction to the appropriate payment product).
Separating orchestration from execution is the architectural decision that makes AP payment programs maintainable at scale. When a new payment product is added, or a supplier's acceptance profile changes, or a buyer adjusts their payment policy, the change is made in the orchestration layer — not scattered across integration code throughout the application.
The ledger. The ledger is the source of truth for every payment in the program: initiated, pending, settled, failed, returned, reversed. It is the data structure that makes reconciliation possible, that gives operations teams visibility into payment status, and that produces the reporting buyers use to manage their AP programs.
AP platform ledgers need to handle: multi-currency if the program serves international payments, multi-buyer account segregation, settlement timing differences across rails (VCard authorization vs. settlement, ACH 1–3 day lag, RTP instant settlement), return and reversal handling, and remittance data attachment at the transaction level. The ledger must reconcile to the bank account balance daily — every dollar in every FBO account must be attributable to a specific buyer and payment record.
Build or buy decision: purpose-built ledger platforms (Modern Treasury, Moov) are appropriate for most AP platforms at $50M–$500M annual volume. They handle the multi-rail, multi-account complexity and integrate with major banks and processors. Custom-built ledgers are appropriate at $500M+ annual volume where the specific requirements — custom reporting, specific bank integrations, proprietary reconciliation logic — exceed what commercial ledger platforms support.
Decision management. Decision management is the policy layer that sits between the orchestration service and the payment execution. It encodes the rules that govern payment behavior: which buyers can use which rails, what approval workflows apply above what thresholds, what supplier payment limits apply by payment type, how exceptions are routed and who reviews them, and what the retry logic is for each failure type.
Decision management needs to be configurable — buyers have different payment policies, and the platform needs to implement those policies without custom code changes for each buyer. A rules engine that encodes buyer-specific policy (amount limits, rail preferences, approval requirements) and platform-wide policy (compliance rules, bank-mandated limits, fraud controls) in a maintainable, auditable form is the correct architecture. Hard-coded payment rules are technical debt that accumulates with every new buyer and every policy change.
Layer 3: The payment product stack
The payment product stack is the set of payment methods the platform offers, arranged to maximize monetization, STP rates, and supplier reach. The architecture principle: the stack should cover every legitimate supplier payment scenario and route every payment to the highest-monetization rail that the supplier can accept for that specific transaction.
Virtual card (the primary monetization rail). Virtual card is the highest-revenue payment rail in AP — generating 150–250 basis points of interchange on eligible transactions. Every AP payments platform should treat VCard as the primary target rail, not a premium option. The product requirements: commercial purchasing card BIN with maximum interchange, single-use card issuance with amount and merchant controls, rich remittance data delivery to the supplier, and AR integration that maximizes STP rates.
VCard partner selection matters. Marqeta provides the strongest developer API and JIT funding capability — appropriate for complex VCard programs with real-time spending control requirements. Direct card processor relationships (with Visa or Mastercard-approved issuing processors) provide better economics at high volume. The right choice depends on program complexity and volume trajectory.
Monetized ACH (the volume rail). ACH is the highest-volume rail in most AP programs — most suppliers accept it, it handles any payment amount, and the mechanics are well understood. Standard ACH generates zero revenue. Monetized ACH — charging a per-payment fee for enhanced remittance, aggregated payment delivery, or accelerated settlement — generates $0.50–$3.00 per payment on volume that otherwise produces nothing.
The monetized ACH product needs: enhanced remittance data delivery (invoice-level detail that enables supplier auto-reconciliation), same-day ACH capability for urgency-priced transactions, aggregated payment capability (combining multiple invoices into a single ACH with itemized remittance data), and guaranteed funds notification for suppliers who need payment confirmation before releasing goods or services.
RTP and FedNow (the speed rails). Real-time payment capability is increasingly expected by business buyers for time-sensitive payments. RTP (The Clearing House) and FedNow (Federal Reserve) both provide instant, irrevocable settlement 24/7/365. The product design for AP: an urgency tier in the payment waterfall that routes time-sensitive payments to RTP/FedNow with a speed premium fee, and a supplier configuration that identifies which suppliers are RTP/FedNow enabled.
RTP and FedNow reach is limited relative to ACH — not all banks have implemented receive capability. The orchestration layer needs to check RTP/FedNow eligibility for each supplier before attempting the rail, and fall back to Same-Day ACH for suppliers not yet on real-time rails.
Wire transfer (the large-value rail). Wires are appropriate for large payments where the cost ($15–$35 per wire) is acceptable relative to the payment amount, and where the irrevocability and speed of wire settlement justify the cost. AP programs should include wire capability for high-value transactions and international payments. Wire should be the last resort in the domestic waterfall — after VCard, ACH, and RTP — but the first option for international payments where ACH doesn't reach.
Check (the legacy rail — last resort by design). Checks remain necessary for suppliers who refuse or cannot accept electronic payment. The check product design for an AP platform: minimize check issuance through every available mechanism, make check issuance as cheap as possible when it is unavoidable, and continuously work the check supplier population down through conversion campaigns.
Check partner selection: outsourced check printing and mailing (Deluxe, CheckFree, similar) eliminates the operational overhead of in-house check production. The platform should capture the check cost savings for buyers ($8–$15 per check eliminated) as a customer value proposition while ensuring the platform's check issuance cost is as low as possible per item.
Check alternatives: the conversion strategy. The gap between "supplier won't accept VCard" and "supplier insists on check" is larger than most AP platforms exploit. Check alternatives — payment methods that eliminate the paper check without requiring full VCard enrollment — convert check volume to electronic at lower per-payment cost.
The primary check alternatives: push-to-card (Visa Direct / Mastercard Send) for suppliers who can receive funds to a business debit or prepaid card without full AR enrollment; digital check (eBill/eCheck) for suppliers who want check-equivalent experience digitally; and supplier portal payments where the supplier logs in to receive payment notification and confirm receipt. Each of these eliminates the check cost for the buyer and reduces the ops overhead of the platform — even when they don't generate interchange, they reduce cost and improve the experience.
Layer 4: Supplier payment limits and cascading routing
Real suppliers have complicated payment acceptance profiles. A supplier may accept VCard for payments under $10,000 but require ACH for larger amounts. They may accept VCard Monday through Friday but not on weekends. They may have card acceptance capability but their AR system has a $5,000 single-transaction limit that the platform can't exceed on a single card. They may accept RTP from some paying banks but not others.
The cascading routing architecture handles these supplier-specific constraints through a routing decision tree that applies them in sequence. For each payment, the routing engine evaluates: is VCard eligible for this supplier at this amount on this day? If yes, attempt VCard. If VCard is declined or exceeds the supplier's VCard limit, is RTP eligible for this supplier from this bank? If yes, attempt RTP. If not, attempt Same-Day ACH for urgent payments or standard ACH for non-urgent. Wire for high-value or international. Check only if all electronic rails have been exhausted or the supplier has explicitly refused electronic payment.
Supplier payment limits by payment type need to be stored in the supplier payment profile and applied by the routing engine dynamically — not hard-coded in the payment flow. A supplier whose VCard limit is $10,000 today may negotiate a $25,000 limit next quarter. The routing engine needs to read the current limit from the supplier profile, not from configuration files that require engineering changes to update.
The routing engine should also manage payment splitting for suppliers with per-transaction limits lower than the invoice amount. A $45,000 invoice to a supplier with a $10,000 VCard limit can be split into five VCard transactions — generating five times the interchange — rather than defaulted to ACH. Payment splitting logic belongs in the orchestration layer, triggered when the invoice amount exceeds the supplier's per-transaction limit for the preferred rail.
Layer 5: Automatic retry and redirect routing
Payment failures in AP programs are not edge cases. VCard declines, ACH returns, RTP routing failures — at $50M monthly, even a 2% failure rate generates 1,000 failed payments monthly that need to be routed to the next best option. The difference between a platform with automatic retry and redirect and one without is the difference between an operations team that handles exceptions and one that is consumed by them.
Automatic retry logic. Not all payment failures are permanent. A VCard decline for "card not accepted" at a supplier who normally accepts cards may be a temporary AR processing issue — retry in 4 hours often succeeds. An ACH return for "account temporarily unavailable" (R02) is retryable; an ACH return for "account closed" (R04) is not. The retry logic needs to classify failures by retryability — not attempt to retry permanent failures, which waste processing cycles and can violate NACHA rules on return code handling.
Retry logic by rail: VCard declines classified as temporary (network timeout, AR system unavailable) retry with configurable delay (4–24 hours). ACH returns classified as retryable (R02, R10) retry once with bank confirmation required before second attempt. RTP failures (network unavailable, participant bank not responding) fall back immediately to Same-Day ACH without retry — RTP failures are typically infrastructure, not supplier issues.
Redirect routing. When a payment fails and retry is either not applicable or has been exhausted, the redirect logic takes over — routing the payment to the next best option in the waterfall. The redirect should be automatic for most failure types, with human review only for exceptions that require judgment: supplier contact required, large-value payments above a threshold, or failure types that suggest a supplier account issue requiring investigation.
The redirect routing should preserve the monetization intent: a failed VCard redirects to monetized ACH rather than standard ACH, capturing the $0.50–$3.00 monetized ACH fee on volume that would otherwise generate zero revenue. Every redirect decision should choose the highest-monetization available rail, not just the most available rail.
Avoiding checks at all costs. The platform's routing architecture should treat check issuance as a failure state — something that happens when every other option has been exhausted or the supplier has explicitly refused electronic payment. Check issuance should trigger: supplier conversion outreach (automatic enrollment invitation), cost recovery from the buyer (the platform should not absorb check costs silently), and escalation to the supplier enablement program.
Most AP platforms issue checks passively — the payment waterfall reaches check and the check is issued without any further attempt to avoid it. Active check avoidance means: before issuing a check, attempt the check alternative stack (push-to-card, digital check, supplier portal) for suppliers who haven't been enrolled for full electronic payment. Some of these alternatives generate zero interchange but eliminate the check cost — which is a net positive for the program economics and the buyer experience.
Layer 6: AR partners and STP optimization
STP rate — the percentage of VCard payments that process automatically through the supplier's AR system without manual intervention — is the single most important operational metric for AP platform monetization. A program at 15% STP is leaving 85% of its VCard interchange opportunity in the supplier's AR queue. Moving from 15% to 40% STP on $200M annual VCard volume at 200 bps generates $1M in additional annual interchange without changing payment volume.
AR integration partners. The AR integration layer is what drives STP from 15% to 40%+. AR integration connects the AP platform's payment notification directly to the supplier's accounts receivable system — so the VCard payment applies to the invoice automatically without any manual AR team involvement. The primary AR integration partners:
AR automation platforms (Billtrust, Versapay, YayPay, Growfin): these platforms sit between the supplier's ERP and its customers' payment systems. An integration with a major AR automation platform reaches thousands of suppliers simultaneously — every supplier using that AR platform can auto-process your VCard payments through a single integration.
ERP-native AR modules (SAP, Oracle, NetSuite, Sage): direct integration with major ERP systems' AR modules enables automatic payment application for suppliers running those systems. ERP integrations require more development effort per integration but reach the highest-volume supplier segments in B2B.
Card-specific AR processing solutions (Mastercard's virtual card receivables automation, Visa's supplier enablement programs): network-level programs that provide suppliers with automated VCard processing tools. Participating suppliers can auto-process all network-compliant VCard payments regardless of which AP platform issued the card.
The AR partner strategy should target: one major AR automation platform integration (highest reach per development investment), ERP integrations for the top 3 ERP systems your supplier base runs, and network-level enrollment for the remainder. The combination of these three approaches can drive STP rates to 40–50% within 18–24 months for programs with active supplier enablement programs.
Remittance data quality. AR integration only drives STP if the remittance data delivered with the payment is in the format the supplier's AR system expects. A VCard payment with a single invoice reference in the memo field will not auto-apply in a supplier's AR system that expects a structured EDI 820 remittance record. Remittance data needs to be delivered in the format the supplier's system can consume — not the format that is easiest for the AP platform to produce.
Remittance data format support: EDI 820 (the standard for large enterprise AR systems), structured CSV or XML (for mid-market ERP integrations), and rich card statement data (for suppliers processing VCard through their card merchant account without a separate remittance file). The platform needs to support all three and map buyer remittance data to the correct format for each supplier.
Supplier enablement as a continuous program. AR integration is not a one-time enrollment. Supplier AR teams turn over. ERP systems get upgraded. Card acceptance configurations get reset. A supplier at 80% STP today can drop to 20% after an AR system migration if the integration isn't maintained. Supplier enablement must be treated as an ongoing operational program — monitoring STP rates by supplier, identifying drops, reaching out when rates decline, and maintaining integrations as supplier systems change.
Layer 7: AI payment execution and routing optimization
AI execution in AP payments operates at two levels: decision optimization (which rail should this payment use, based on real-time data about this supplier and this payment) and execution automation (initiating payments within defined policy parameters without per-transaction human approval). Both are relevant to a high-performing AP platform; they serve different purposes and require different architectural design.
AI routing optimization. The static waterfall — try VCard, fall back to ACH, use check as last resort — is a rule-based approximation of good routing. An AI routing model is a dynamic optimization: it predicts acceptance probability for each rail/supplier combination based on historical transaction data, and routes to the rail most likely to succeed and generate the highest monetization for this specific payment.
The model inputs: supplier's historical VCard acceptance rate (overall, by day of week, by amount range), current AR system configuration status, recent failure patterns, payment amount vs. supplier's known per-transaction limits, and time sensitivity. The model output: a ranked rail sequence with confidence scores that the orchestration layer uses to select the primary rail and fallback sequence.
At scale, the monetization impact is significant. A routing model that improves VCard routing accuracy by 5% — directing 5% more payments to VCard that would have defaulted to ACH under static rules — generates approximately $1.75M in additional annual interchange at $200M annual payment volume and 200 bps interchange rate.
AI payment execution within policy bounds. For AP platforms serving buyers who want to reduce manual approval overhead, AI execution within defined policy parameters enables straight-through payment processing for the majority of invoices. The buyer defines the policy: pay any invoice under $5,000 that matches a verified PO from an approved supplier automatically. The AI evaluates each invoice against the policy and executes payments that qualify without per-invoice human review.
The compliance architecture for AI execution (authorization chain documentation, OFAC screening in the execution loop, spending controls as compliance layer) is covered in detail in the related post on AI-initiated VCard compliance. The key requirement for AP specifically: the authorization trace for every AI-executed payment must include the policy rule the payment matched, the invoice and PO data used in the decision, the OFAC screening result, and the spending controls applied. This trace is the compliance record that supports the payment's legitimacy when the buyer's auditor or the sponsor bank's examiner reviews the program.
Predictive exception identification. AI can identify payments likely to fail before they are initiated — based on patterns in the supplier's recent AR behavior, changes in their bank account status, or anomalies in the payment amount relative to normal transaction patterns. Flagging likely-failure payments before execution allows the orchestration layer to route them to the next-best rail immediately rather than initiating, failing, waiting for the return notification, and then re-routing. For ACH payments, where the failure notification arrives 1–3 days after initiation, predictive routing can eliminate days of payment delay.
Layer 8: Transparent status, proof of payment, and supplier experience
A high-performing AP payments platform is not just one that moves money efficiently. It is one that both buyer and supplier can trust — because they can see exactly where every payment is at every point in its lifecycle.
Real-time payment status. Every payment in the platform should have a real-time status that reflects its actual state: initiated, authorized (VCard), in transit (ACH pending), settled, returned, or failed. This status should be visible to the buyer in their AP workflow and queryable by the supplier. Status updates should be driven by actual settlement events — not estimated based on rail timing — so the status the buyer sees matches the economic reality.
Proof of payment. Suppliers increasingly require proof of payment before releasing goods, completing services, or closing invoices in their AR systems. Proof of payment for electronic payments: VCard authorization confirmation with spending controls visible to the supplier (proves the card is valid and the funds are committed), ACH prenote or credit advice notification (confirms the ACH was initiated and provides settlement date), RTP settlement confirmation (instant and irrevocable — the strongest proof of payment available), wire transfer confirmation (SWIFT MT103 or Fedwire confirmation).
The platform should generate proof of payment documentation automatically for every payment type and make it available to the supplier immediately after execution. Manual proof of payment requests — supplier calls the buyer's AP team to confirm a payment — are an operations burden that the platform should eliminate entirely for electronic payments.
Supplier payment portal. A supplier-facing portal that provides: payment status visibility (where is my payment?), remittance data access (which invoices does this payment cover?), enrollment management (update bank account, enroll for VCard, set payment preferences), and dispute initiation (report a payment issue). The portal eliminates most supplier payment inquiries — which are among the highest-volume AP operations tasks — and enables suppliers to self-serve their enrollment and preference management.
The portal is also the primary check alternative enrollment channel: suppliers who receive a check and want to switch to electronic can enroll through the portal without requiring buyer or platform staff intervention. Every portal enrollment converts a check to electronic — improving buyer experience, reducing platform ops cost, and potentially adding monetization if the supplier enrolls for VCard.
The performance metrics that matter
A high-performing AP payments platform is measured by four metrics that capture the full value of the architecture described above:
Electronic payment rate: the percentage of total payment volume delivered electronically (all rails except check). Best-in-class programs reach 90–95% electronic. Programs below 75% have significant check conversion opportunity.
VCard acceptance rate: the percentage of total payment volume delivered via virtual card. Best-in-class programs reach 35–45%. Programs below 20% have significant VCard enablement opportunity in the supplier base.
STP rate: the percentage of VCard payments that process automatically without manual AR intervention. Best-in-class programs reach 40–55%. Programs below 25% have significant AR integration and supplier enablement work to do.
Effective take rate: total payment program revenue divided by total payment volume processed. Best-in-class AP platforms reach 80–120 basis points. Programs below 40 basis points have architecture gaps — BIN economics, BaaS middleware share, monetized ACH gap, or fee structure gaps — that are worth diagnosing specifically.
These four metrics tell you exactly where the architecture is performing and where it isn't. A program with a 90% electronic rate and a 15% VCard acceptance rate has a supplier enablement problem. A program with a 35% VCard acceptance rate and a 25% STP rate has an AR integration problem. A program with a 40% VCard acceptance rate, 45% STP rate, and 40 basis point take rate has a program economics problem — BIN, BaaS share, or fee structure.
Putting it together
A high-performing, high-monetizing AP payments platform is not a product feature or a technology choice. It is an architecture — eight layers designed to work together, each dependent on the ones below it, each measurable in isolation.
The foundation (program model and bank structure) determines the economics ceiling. The orchestration, ledger, and decision platform makes the program operable at scale. The payment product stack covers every supplier scenario. The cascading routing and automatic retry logic minimize manual exceptions. The AR partner integrations drive STP rates that make VCard economics real. The AI execution layer makes routing decisions faster and more accurate than static rules. And the supplier experience layer — status, proof of payment, self-service portal — eliminates the ops overhead that grows with volume in programs that don't invest in it.
The programs that get this right generate 80–120 basis points on payment volume, reach 40–50% VCard acceptance rates, run 40–55% STP rates, and process 90%+ of payments electronically. The programs that don't are leaving $1M–$4M annually on the table at $200M annual payment volume — in economics that are recoverable with the right architecture.
Building or rebuilding an AP payments platform? See how ExpandUp approaches AP payment program design, or talk with us directly — we can diagnose exactly where your program's architecture gaps are in 30 minutes.