LAST-MILE AUTHORITY BINDING FOR AI PAYMENTS

The approval and provider request are different objects.
Prove they still match.

Bind a supported signed final approval to the exact Stripe PaymentIntent request your executor is about to send—and keep authority locked until MandateShield checks the resulting PaymentIntent. The exclusive executor still makes an idempotent provider operation; MandateShield does not move money or replace native provider controls.

First commercial profile: supported signed approval → Stripe PaymentIntent. Exclusive credential routing is required. The public lifecycle is test-only and contacts no provider.

EXECUTION INTEGRITY TRACE

#ms_interactive

BLOCKED

Provider call attempts

$1,499.00
APPROVED REQUEST

Exactly $124.00 at Rail Merchant, bound to one provider request.

!

The provider request changed after approval. Amount, payee and request digest no longer match.Attempted payee: Unknown Seller

No provider submission is permitted.BINDING_MISMATCH

Exact boundary implemented today

Signed final approvalExact Stripe request digestUNKNOWN stays reserved
Mandate = delegated AI purchase authority.Not SEPA · Not direct debit · Not e-signature · No money movementExact category definition →

THE GAP

An approved decision is not the executed provider call.

A policy engine may allow “$124 at Rail Merchant.” A changed checkout, compromised tool, concurrent worker or retry can still present a different request—or attempt the approved request again.

MandateShield rechecks exact bindings before granting one fresh permit claim and then checks supported terminal evidence without trusting the caller's result. The exclusive executor and provider idempotency remain required for the downstream operation.

BEST FIT TODAY

One last-mile integration problem, handled explicitly.

MandateShield is deliberately narrow. It is useful when a signed approval and the final provider call are produced by different components, so neither artifact alone proves that the approved checkout is the request the executor actually attempted.

Do not buy it for generic guardrails. Native budgets, seller scopes, fraud controls and payment credentials stay with their providers. MandateShield is for the remaining signed-approval to exact-provider-request gap on the explicitly supported path.

ACCOUNT EMERGENCY STOP

Pause every path that is forced through the MandateShield Gate.

Once PAUSE commits, no competing strict reservation, PROCESSOR CONSUME or execution-permit redemption can win afterward on a correctly integrated MandateShield-mediated path.

Evidence does not go dark during an incident. Receipt verification, provider outcome reporting and reconciliation remain available so already-submitted attempts can reach a truthful final state.

Deployment boundary: provider credentials must be absent from the agent runtime and alternate provider egress must be blocked. MandateShield cannot stop a bypass path or recall an execution step that committed before PAUSE.Open the execution control center →

CHOOSE THE REAL EXECUTION PATH

Start with the seam you actually need to close.

The primary integration path is supported signed approval to Stripe. The x402 profile is retained for compatibility and evidence testing; it is not presented as a replacement for x402's native authorization, nonce, idempotency or settlement controls.

YOUR FASTEST PATH

Bind a supported signed approval to the exact PaymentIntent request.

Carry the approved checkout facts into the connected account, payee, amount, currency and exact Stripe form-body digest without giving the agent a payment credential.

WHAT YOU GETA verifiable last-mile link between the signed approval and the customer-controlled Stripe executor.Inspect the AP2-to-Stripe seam
01

Resolve exact authority

Send the final purchase plus signed authority evidence. The engine verifies identity, bindings, budgets, consent, expiry and replay outside the model.

02

Claim one provider attempt

Reserve the approved authority, consume it once and redeem a provider-bound permit at the credential-isolated execution edge. Only the fresh atomic winner receives MandateShield permission; the executor must still make one idempotent provider operation.

03

Verify and prove the outcome

MandateShield checks the configured provider API or canonical chain evidence without relying on the caller's asserted result. Final state and evidence are bound into a portable ES256-signed execution receipt verifiable with published keys.

WHAT CHANGES

One fresh claim gates authority. Provider evidence closes the outcome.

$0card data sent to MandateShield
fresh atomic redemption per provider submission
strong outcome sources: provider API or finalized chain

FREE LIVE VALIDATOR

See the decision before you integrate.

Change the money or permissions with plain controls, then attack the same mandate five ways. The results come from the live public analysis API—not a recorded animation. Sandbox results are never executable.

LOAD A SCENARIO

Live policy engine · no account · no card or personal data

READY

Change the purchase. See where authority ends.

Run one decision or test the same mandate against five boundary failures.

Developer mode: edit the complete JSON envelope
purchase-envelope.json
Sent only to this live sandbox

Ready for inspection

Run the sample or change a constraint to see the verdict.

EXACT SUPPORT BOUNDARY

Accepted labels are not execution support.

Terminal outcome checking exists only for configured Stripe PaymentIntents and the supported x402 EIP-3009 profile. Three narrow input projections help normalize selected AP2, x402 and MPP fields. TAP, UCP, ACP and custom values are labels only; none of these labels establishes protocol conformance.

Inspect the exact support matrix →
Stripe PITerminal outcome checked through Stripe
x402 EIP-3009Terminal outcome checked on canonical chain
AP2One narrow input projection
x402 inputPAYMENT-REQUIRED projection
MPPOne charge-challenge projection
TAP · UCP · ACP · customNormalized labels only
VERIFY → REDEEM → SUBMIT → RECONCILELIVE
const reservation = requireAllowed(await verifier.verifyAuthority({
  envelope: purchase,
  evidence: signedAuthority
}))
const consumed = await processorGate.transitionExecutionAuthorization({
  receipt_id: reservation.signed_receipt.receipt_id,
  compact: reservation.signed_receipt.compact,
  expected_envelope: purchase,
  expected_audience: processorAudience,
  action: "CONSUME",
  idempotency_key: `${attemptId}:consume`,
  provider_binding: exactProviderRequest
})
const redeemed = await providerGate.redeemExecutionPermit({
  permit_id: consumed.execution_permit.permit_id,
  compact: consumed.execution_permit.compact,
  expected_audience: processorAudience,
  expected_request: exactProviderRequest,
  idempotency_key: `${attemptId}:redeem`
})
if (!redeemed.provider_submission_permitted || redeemed.idempotent_replay) {
  throw new Error("No fresh provider claim")
}
const outcome = await submitOnceToProvider({
  idempotencyKey: redeemed.provider_idempotency_key
})
const terminal = await providerGate.reportProviderSubmission({
  provider_submission_id: redeemed.provider_submission_id,
  permit_id: redeemed.permit_id,
  claim_id: redeemed.claim_id,
  payment_reference: outcome.reference,
  outcome: outcome.status,
  occurred_at: outcome.occurredAt,
  provider_observation: outcome.boundedObservation
})
// independent_verification means independent of the caller's assertion.
// It is not an independent organization, certification or audit.
if (!terminal.independent_verification) {
  await queueProviderReconciliation(redeemed.provider_submission_id)
  throw new Error("Outcome remains fail-closed")
}
verifyExecutionReceipt(terminal.execution_receipt)

ONE FRESH CLAIM, CHECKED OUTCOME

Bind the approval. Execute idempotently. Check the result.

Production adds an immutable mandate registry, account-pinned issuer keys, one-time challenges, atomic cumulative-budget reservations and durable receipts. A first-party Gate adapter runs inside customer infrastructure, isolates the provider credential and is responsible for one idempotent bound provider operation. Hosted Reconcile then checks the exact configured Stripe PaymentIntent or x402 chain outcome without trusting the caller's report. The hosted API is designed not to collect card data, customers must not submit it, and MandateShield does not settle money.

Availability is part of the safety tradeoff: if hosted strict verification or reconciliation is unavailable, MandateShield does not grant a new authorization and an unresolved outcome stays reserved. That can pause checkout. Integrations should queue safely or route to manual review; they must not fail open or blindly retry a provider operation.

  • Separate VERIFY and audience-bound PROCESSOR keys
  • Lifetime, UTC-day and UTC-month cumulative spend limits
  • One fresh permit claim before an idempotent submission
  • Caller-independent Stripe and x402 outcome checks; no external audit claim
  • Caller reports and signed webhooks remain hints, not trust
  • UNKNOWN stays budget-consuming and forbids blind retry
  • Portable ES256 decision and execution receipts
  • Versioned OpenAPI, schemas, SDKs, checksums and SBOM
Read the API docs →

COMPARE PUBLISHED PLAN COST

See cost per decision without inventing avoided losses.

Set your volume and average purchase. The calculator finds the lowest-cost published plan and shows effective software cost per 1,000 decisions and as a share of the average purchase. It makes no savings, loss-prevention or return-on-investment claim.

ESTIMATED SOFTWARE COST PER PURCHASE DECISION$0.001

Lowest-cost planGrowth

Estimated monthly cost$499.00

Software cost / 1,000 decisions$0.998

Share of average purchase0.0008%

This is published plan pricing divided by your stated volume and average purchase value. It is not a loss estimate, ROI claim or promise of savings.

Choose Growth

START FREE, SCALE BY USAGE

Production from $99. Machine scale at $0.10 per 1,000.

No sales call, seat fee or annual contract. Create the account, choose a plan and create role-scoped live keys in the dashboard. Machine includes 50 million decisions for $4,999 per month.

Most popular$499/month

500,000 verification decisions included

Compare all plans →

LEARN WITHOUT A SALES CALL

Everything needed to make the decision.

Practical, evergreen references for merchants and developers implementing autonomous checkout.

CRYPTOGRAPHIC LAB

Prove signed purchase authority

Generate and verify a signed, deliberately non-executable decision.

AP2 · X402 V2 · MPP BRIDGE

Project documented payment fields

See every mapped binding and the non-executable assurance boundary before account-pinned authority is signed.

X402 V2 COMPATIBILITY PROFILE

Inspect the additional MandateShield boundary.

See exactly what MandateShield adds around EIP-3009—and what remains native x402 authorization, nonce, idempotency and settlement behavior.

PROVIDER-VERIFIED STRIPE

Connect one permit to one PaymentIntent

Verify exact account, amount, currency, reference and status from Stripe itself; treat webhooks only as wake-up signals.

RELEASE INTEGRITY

Verify the SDK and its dependencies

Versioned SHA-256 checksums, offline verification and SPDX SBOM.

BUYER AND AI DUE DILIGENCE

Evaluate the evidence, including what is absent

One graded index for the correct product identity, official external records, repeatable checks and facts not yet established.

FREE ASSESSMENT

Score your payment boundary

Ten questions produce a prioritized, shareable action plan.

FREE BUILDER

Generate testable authority

Create fresh mandate JSON, copy curl and run the live engine.

MERCHANT GUIDE

AI agent payment security

Seven controls to verify before accepting an agent purchase.

AP2 CHECKLIST

Runtime mandate validation

Binding, expiry, replay and audit evidence for production.

MCP IMPLEMENTATION GUIDE

Keep payment power outside the model

Connect callable tools to a consume-once authorization boundary.

VERSIONED EVIDENCE

Inspect every control claim

Map deterministic, cryptographic and execution claims to public contracts and machine-readable evidence.

ARCHITECTURE COMPARISON

Policy ALLOW vs. execution integrity

See which gap remains after budgets, scoped credentials and provider-native controls have already done their job.

ARCHITECTURE

Security and threat coverage

Exactly what MandateShield checks—and what it does not claim.

RESOURCE LIBRARY

Solutions and payment threats

Implementation paths for every team and failure mode.

PLAIN-ENGLISH ANSWERS

Common questions about AI-agent payment control.

Is MandateShield SEPA or direct-debit mandate software?

No. MandateShield checks bounded authority for autonomous AI-agent purchases. It does not collect IBANs, signatures, debit instructions or payment credentials.

Is MandateShield the same company as Mandatory Shield, ShieldAD or ADSecure?

No. MandateShield at mandateshield.com is AI-agent payment-authority software operated from Bern, Switzerland. It is unrelated to Mandatory Shield Company at mandatoryshield.com, its Brussels team, ShieldAD/ADSecure and Microsoft Active Directory auditing.

What does MandateShield do?

MandateShield binds a supported signed final approval—including its narrow AP2 closed-payment projection—to the exact provider request a credential-isolated executor is about to send. It reserves approved spend, grants one fresh online claim and can check the configured Stripe or x402 outcome without trusting the caller's report before producing a signed execution receipt.

Who is it for?

MandateShield is built first for teams turning externally approved AI-agent checkout facts into Stripe PaymentIntent requests while keeping credentials behind one exclusive executor. A supported x402 EIP-3009 profile remains available as a narrow compatibility profile, not as a claim that MandateShield replaces its native controls.

Does it replace a payment processor or fraud tool?

No. It adds a stateful execution-authority and reconciliation layer. A credential-isolated gateway must freshly redeem the exact permit before attempting an idempotent provider operation. That single-winner claim is not an exactly-once provider-delivery guarantee. MandateShield can then verify a configured Stripe PaymentIntent or x402 chain outcome; card processing, fraud scoring, sanctions screening and settlement remain with existing providers.

Does MandateShield receive card data?

No. The API evaluates policy metadata such as amount, currency, merchant, consent and expiry. Payment credentials stay with the merchant's payment provider.

Can one control pause MandateShield-mediated execution?

Yes, within one account when provider credentials and egress are isolated behind the required MandateShield Gate. The interlock atomically blocks new strict reservations, PROCESSOR consumption and permit redemption on MandateShield-mediated paths. Receipt verification, outcome reporting and reconciliation remain available. It cannot stop alternate customer infrastructure that bypasses the Gate or recall a step that committed before the pause.

Which agent-payment protocols are supported?

The normalized policy envelope can label AP2, TAP, UCP, x402, MPP, ACP or custom inputs, but a label is not protocol conformance. Built-in field projection is limited to an AP2 terminal closed-payment projection, x402 v2 PAYMENT-REQUIRED input and one explicitly profiled MPP Payment charge challenge. Terminal outcome profiles exist only for configured Stripe PaymentIntents and the documented x402 EIP-3009 path. Full AP2 checkout chains, MPP method credentials, Visa TAP trust stores and the remaining protocol stacks stay external.

AUTONOMY NEEDS BOUNDARIES

Authorize. Enforce. Verify. Prove.

Check a purchase free