-
-
Original diagram. Fictional sandbox demo.
Inspiration
A shopping assistant may propose the right products and still hand over the wrong checkout: a quantity, delivery charge or address can change after someone says yes. A general “approved” flag does not show which basket was approved. Cart Consent makes that decision specific and reviewable.
What it does
The working Python CLI and local JSON API bind approval to the exact catalog items, quantities, prices, currency, budget, shipping option and charge, recipient address, merchant and payment mode. A critical change invalidates approval. Separate agent and human HTTP capabilities let an agent propose or edit a basket, while only the human capability can approve its current fingerprint and request a checkout link. The ledger rechecks revision, catalog and approval after an upstream request, withholding a link if the approved state changed during the call.
How we built it
The implementation uses Python's standard library, SQLite transactions, integer minor-unit amounts, SHA-256 snapshot fingerprints, expiring approvals and persisted request identities. The catalog owns prices and shipping charges; model output is restricted to known SKU/quantity selections and an explanation, then independently validated. The optional local Ollama planner has no approval or payment tools. Structured shipping-address fields are omitted from its prompt, although free-text goals are sent unchanged and must not contain sensitive information.
The payment adapter uses PayPal's official sandbox OAuth and Orders v2 endpoints. It requests a complete representation and checks the returned amount, items, shipping, merchant and snapshot identifiers before releasing an allowed sandbox approval URL. It implements neither production mode nor a capture endpoint.
What actually ran
On November 10, a fresh local qwen2.5:0.5b proposal through Ollama 0.40.15 returned in 5.899 seconds, selecting one fictional pen set. USD 8.99 plus USD 4.99 shipping totaled USD 13.98, below the USD 50.00 budget. The result remained an unapproved DRAFT. The developer reviewed the complete fictional snapshot and explicitly approved its exact fingerprint through the local CLI.
The real PayPal sandbox then returned PAYER_ACTION_REQUIRED for one unpaid order. The existing adapter validated the representation without a code change. An earlier attempt failed at OAuth HTTP 401 before any Orders request; duplicated private configuration was corrected while retaining the same cart, fingerprint, approval nonce and saved request ID. The successful checkout CLI invocation took 1.369 seconds. The raw success HTTP status was not recorded. A guarded subsequent checkout CLI call returned the cached existing order with zero network calls. That verifies local cached replay, not remote idempotency. A sanitized evidence record is included in the repository; credentials, account/order identifiers and approval URLs remain private.
This was a developer-operated synthetic demonstration, not authenticated real-buyer consent. The approval URL was not opened. No buyer login, checkout, authorization, capture, completed purchase or production payment occurred. CAPTURE is an order intent field, not evidence of an executed capture. The HTTP agent/human role tests are separate mock demonstrations. Earlier November 6 local-model evidence, including timeouts and an over-budget rejection, remains available rather than being replaced by the successful run.
Challenges and limits
The difficult boundary is preserving the same reviewed state through edits, expiration, concurrent changes and ambiguous upstream failures. Saved attempt identities prevent blind retries with new keys. Local revocation blocks this application's future retrieval; it cannot cancel a remote URL already disclosed. The prototype assumes one local buyer ledger and does not establish multi-tenant identity, fraud prevention, real tax/shipping/address validation, model-quality performance or AP2 certification. Strict response matching may reject account responses with additional normalized fields; one successful run does not prove universal compatibility.
Build disclosure and next steps
Codex assisted design, coding, tests and documentation. Runtime AI is the explicitly configured local Ollama model; default rule-based mocks disclose ai_used=false. This is an original MIT-licensed implementation. PayPal Agent Toolkit and Google AP2 were reviewed as existing design/protocol comparisons; no copied code, schemas or assets are claimed. Approval-bound checkout already exists, so this is a focused consent gate rather than a new payment protocol.
The repository has runnable CLI/API instructions and a successful narrow AI/sandbox integration record. The public English demonstration is published at 138.8 seconds. It combines edited sanitized evidence cards with an actual mock-mode native terminal shot, rather than continuous footage. Generic synthetic Aria narration and 25 English captions accompany the edit; full audio/video decoding passed, with no full manual listening claim.
