Provider Settlement Adapters

Provider settlement adapters let OpenPermit authorize machine payments while an external provider, network, processor, facilitator, or seller rail executes and settles funds.

The adapter model keeps OpenPermit rail-neutral:

• OpenPermit verifies mandates, policy, budgets, evidence, and revocation state.
• The provider issues or verifies payment credentials, vouchers, or network tokens.
• The seller receives settlement through the provider rail.
• OpenPermit records receipts, settlement references, reconciliation reports, and audit evidence.

Mastercard AP4M

Mastercard Agent Pay for Machines is a future provider-adapter candidate. It combines agent credentialing, permissioning, offchain verification, aggregate settlement submission, and Mastercard-backed multi-rail settlement.

OpenPermit should model Mastercard/AP4M as a future provider behind existing payment methods and settlement modes:

• Use hostedOrProcessor when a Mastercard-connected provider executes payment and settlement through processor or network infrastructure.
• Use batchedSettlement when OpenPermit authorizes individual machine actions and later reconciles aggregate provider settlement reports.
• Store AP2/Verifiable Intent, Web Bot Auth, provider credential, voucher, and settlement report hashes as authorization or settlement evidence.
• Label settlement assurance as providerGuaranteed only when the provider path supplies the guarantee.

Future Fields

Future APIs should add these optional fields before runtime provider integration:

• authorizationEvidence[] on mandates, payment intents, authorizations, executions, receipts, and settlement reports.
• provider on fee quotes, executions, receipts, and settlement reports.
• settlementAssurance with values such as providerGuaranteed, onchainFinality, processorBalance, batchPending, and none.
• batchSettlementReference on receipts and settlement reports.
• reconciliationReportSource for provider settlement reports, invoices, card/acquirer reports, or batch contract events.

Acceptance Criteria

The first provider-adapter implementation should prove four scenarios:

• A VI/AP2 evidence artifact is attached to an OpenPermit mandate or payment intent by hash.
• An x402 or MPP payment records authorization evidence on the resulting receipt.
• A Mastercard/AP4M-style provider adapter records provider-backed settlement assurance without claiming OpenPermit-backed settlement.
• A dispute review can connect mandate, policy decision, evidence hash, delivery status, payment credential, settlement reference, and provider reconciliation reference.