Short description

Payments do not end when a buyer clicks “Pay”. PayPal 360 gives a commerce team one place to follow an order from PayPal Sandbox checkout through capture, webhook reconciliation and the operational work that may follow. Automation is constrained by roles, scopes and business policy, while sensitive actions can wait for human approval and every important decision is recorded.

Inspiration

Commerce teams often have to reconcile several disconnected questions: Did the customer really pay? Did the provider confirm it? Which internal action should happen next? Is an agent allowed to request that action? Who approved it, and what evidence will be available later?

PayPal 360 was created to explore a safer answer: connect payment events to business operations without treating automation as an opaque black box.

What it does

  • Creates a PayPal Sandbox checkout from a server-validated product and price snapshot.
  • Supports buyer approval and payment capture with durable request and idempotency records.
  • Receives and verifies PayPal webhooks through a public HTTPS endpoint.
  • Stores webhook events durably and applies them idempotently.
  • Shows order state, provider references and audit history in a merchant dashboard.
  • Allows AI or internal agents to propose follow-up work within assigned permissions.
  • Applies configurable policy: automatic, approval-required, human-only or blocked.
  • Records actors, decisions, outcomes and provider references for later review.
  • Fails closed for provider actions that do not yet have an approved contract or handler.

Why it is useful

PayPal 360 helps a business reduce manual coordination around routine orders while retaining control over consequential actions. It makes the boundary between verified payment, proposed work, approved work and unfinished integration explicit.

The result is a workflow that is easier to operate, investigate and extend:

checkout → capture → signed webhook → reconciliation → policy decision → audited follow-up

How it was built

  • .NET 10 application with a local SQLite-backed prototype store.
  • PayPal Sandbox Orders and Captures APIs.
  • PayPal webhook signature verification and durable inbox processing.
  • HttpOnly checkout sessions, authenticated merchant sessions and hashed agent credentials.
  • Tenant-scoped roles, resource scopes and policy-aware action requests.
  • SHA-256 audit hash chain with export and optional signed checkpoint support.
  • Local HTTPS UI plus a certificate-authenticated reverse tunnel for the PayPal webhook route.

Verified demonstration

The verified Sandbox path is:

  1. Create a checkout order.
  2. Approve it as the buyer.
  3. Capture the payment.
  4. Receive PAYMENT.CAPTURE.COMPLETED through the public HTTPS webhook route.
  5. Verify, persist and apply the webhook once.
  6. Reconcile the local order and inspect the audit history.

The local inbox recorded the signed capture event as APPLIED, with corresponding provider receipt and application audit entries. Build, HTTP integration and UI checks pass for the repository state used for the demonstration.

Challenges we addressed

  • External PayPal calls cannot share a transaction with local database writes, so intent, idempotency and reconciliation are persisted explicitly.
  • Webhooks can be delivered more than once or arrive after a process restart, so the inbox and event application are durable and idempotent.
  • Automation must not exceed delegated authority, so effective permissions are intersected with merchant policy, role delegation and resource scope.
  • A local prototype should not be presented as production infrastructure, so unsupported provider actions remain unavailable and deployment limitations are visible.

What makes the approach different

PayPal 360 treats payment as the beginning of an accountable business workflow rather than the end of a checkout screen. It combines provider reconciliation, agent permissions, human approval and audit evidence in the same model, while keeping unverified integrations visibly unverified.

Future work

  • Approve and implement refund, fulfillment and catalog-publication provider contracts.
  • Add a bounded, initially read-only Google Merchant Center connector.
  • Move audit exports and signed checkpoints to independently owned retention storage.
  • Replace the local tunnel and SQLite prototype with supervised production infrastructure.
  • Add managed secrets, monitoring, backups, recovery testing and production-readiness review.

Built With

  • .net
  • c#
  • mcp
  • paypal
  • paypal-javascript-sdk
  • paypal-orders-api
  • paypal-sandbox-webhooks
Share this project:

Updates

Submission history