Payment Management

Within the SADAR Semantic Registry, Bilateral Payment Matching allows autonomous agents to agree on commercial terms programmatically during the discovery phase, ensuring that financial compatibility is established before any runtime invocation occurs. In the larger context of Entity and Service Specifications, this matching process relies on a strict hierarchical relationship between an accountable organization and the capabilities it offers.

Here is how bilateral payment matching functions acrossEntity and Service Specifications:

1. Entity-Level Declarations and the Direction Field At the Entity level, organizations declare their available payment methodologies (e.g., ACH, credit card, invoice, X.402 networks). Crucially, the entity specification requires a direction field for each payment method, which is explicitly used to drive bilateral payment method matching during service discovery. The direction can be set to:

• PAYABLE:     The entity uses this method as a consumer (paying for services).
• RECEIVABLE:     The entity uses this method as a provider (receiving payment).
• BOTH:     Applicable in either direction.

By establishing this directionality, the registry can deterministically match a requesting agent capable of paying via a specific method with a provider service configured to receive payments via that same method.

2. Service-Level Referential Integrity and Restrictive Terms While the Entity defines the overarching payment capabilities, the Service Specification acts as the actual "discovery and filtering surface" for a specific capability. The registry enforces strict referential integrity between the two:

• Strict     Subset Rule: Every payment method advertised by a service MUST exist     in the ACTIVE version of its directly owning entity's payment methods     array. A service cannot inherit or reference payment methods from parent     entities further up the organizational hierarchy.
• Restrictive     Terms: A service can define its own service_specific_terms (such as     net_days, minimum_amount, maximum_amount, and currency). However, the     registry validates that any service-specific terms must be equal to or more     restrictive than the owning entity’s declared terms for that same     payment method (e.g., enforcing a lower maximum amount or a shorter     net-days window).

If an entity removes or expires a payment method, the registry automatically blocks the update until any dangling service references are resolved, ensuring that services never advertise orphaned payment methods.

3. Separation of Discovery from Sensitive Settlement Data A core design principle of these specifications is that they only hold metadata for discovery filtering. No sensitive financial account numbers, routing numbers, or payment instruments are ever stored in the Entity or Service manifests.

Because the registry isolates discovery from execution, the actual exchange of payment instrument metadata and settlement configuration occurs directly between the consumer and the producer via the OpenID Connect(OIDC) handshake after discovery is complete.

The Larger Context Ultimately, by embedding bilateral payment matching directly into the Entity and Service Specifications, the SADAR architecture supports autonomous service interaction without the need for runtime payment negotiation or per-transaction payment authorization. Agents can discover, filter, and invoke paid services dynamically, knowing that all financial, operational, and settlement prerequisites have already been mutually satisfied.

Payment Details

In the SADAR Semantic Registry, payment methodology matching occurs strictly at the discovery layer as a filtering mechanism, while actual payment settlement is handled entirely out-of-band by external providers.

Payment Methodology Advertisement and Matching Providers advertise their financial parameters directly in their entity manifests. This includes:

• Supported     Settlement Models: Subscriptions, metered postpaid (usage-based),     invoiced settlement, and prepaid capacity.
• Settlement     Providers: External processors such as Stripe, PayPal, banking     gateways, or X.402 networks.
• Payment     Methods: Mechanisms like ACH, credit cards, or digital wallets.

To perform bilateral matching during discovery, the registry utilizes a direction field (set to PAYABLE, RECEIVABLE, or BOTH). This ensures that a requesting agent capable of paying via a specific method is deterministically matched with a provider service configured to receive payments via that exact same method. Crucially, the registry uses this data purely as a discovery and filtering surface.

Settlement Agreement Negotiation Once a compatible service is discovered and a connection is established, the requester and the provider finalize the settlement agreement directly. During this phase, the provider returns a settlement configuration that outlines the billing model, pricing, currency, and a settlement recipient identifier (such as a Stripe acct_xxxxxx or a PayPal merchant_id). This public identifier allows the requester to authorize payments with the settlement provider without revealing the service provider's sensitive underlying bank details.

How Actual Payments Work The architecture is purposefully designed to support autonomous interactions without requiring per-transaction payment authorizations before every single service call, which would introduce severe runtime bottlenecks.

Instead, actual payments work through the followingmechanisms:

• Account     Standing: Service execution is governed by the requester's overall account     standing rather than authorizing individual transactions in real-time.     For example, a runtime execution might simply consume a prepaid balance,     add to a metered monthly invoice, or rely on an active subscription.
• Registry     Isolation: The Semantic Registry acts purely as a metadata catalog. It     never processes payments, stores payment instruments, or validates     settlement transactions. Furthermore, sensitive payment data is never     transmitted via registry manifests, OIDC identity tokens, or runtime     service invocation requests.
• External     Settlement: The actual collection of payment instruments, management     of billing agreements, and execution of the financial settlement are the     sole responsibility of the designated external settlement provider. The     service provider handles the usage metering and billing generation, while     the settlement provider handles the actual money movement.

‍