How Pine/Plural and Bank-Owned Payment Handoffs Fit into OACP

Summary

Update, 20 October 2026. Since this post was written, Grantex signs every OACP artifact (ES256) and AgenticOrg's main branch checks each signature before caching. A fixed-rule arbiter now decides every purchase handoff, POS handoff and checkout completion, allow or refuse, without waiting for a person, and a ledger records each commerce change. UCP and ACP checkout, Grantex mandates and a Plural payment executor exist behind switches that default to off, so with the defaults nothing moves money. The AgenticOrg changes are not yet in its production deployment. The newer post 'OACP explained: one trust layer under UCP, ACP and AP2' has the current picture. Correction: the buyer journey section used to list human confirmation requirements; it now says the arbiter's fixed rules decide. Nobody on the merchant side approves a purchase, and only the buyer confirms their own.

The reference architecture keeps mandate and payment execution with the selected provider. The repository's Pine Labs Plural/P3P path supplies design material for capability verification and redacted evidence references; provider promotion remains unverified.

Beyond Pine/Plural

Merchants may also configure bank-owned rails, fintech rails, custom providers, or no provider. Those configs are useful for onboarding and readiness, but they stay non-executing until an approved adapter, provider contract, webhook verification, sandbox tests, and production rollout exist.

Buyer Journey

When a buyer asks to buy, AgenticOrg checks artifact validity, price and inventory freshness, merchant policy, provider capability and channel risk, and the arbiter decides allow or refuse under fixed rules. If allowed, it prepares a provider-owned handoff. If not, it returns a blocker with the failing rule.

Secret Boundary

AgenticOrg and Grantex must not store raw card, bank, UPI, payment URL, checkout URL, provider token, or raw callback payload material in OACP artifacts or cache records.