Introduction

OpenCheckout is an open-source, self-hosted checkout system for accepting payments on the web. It provides a hosted checkout page and a Checkout Sessions REST API that you deploy on your own infrastructure. Your customers pay using their Open Payments wallet address — a URL-based identifier for their bank account, digital wallet, or mobile money account.

Under the hood, OpenCheckout orchestrates the full Open Payments protocol flow:

1. Creates an incoming payment on your wallet to receive funds
2. Requests a quote from the customer’s account provider to confirm the payment cost
3. Facilitates an interactive grant where the customer approves the payment at their own financial institution
4. Issues an outgoing payment instruction to move the money

OpenCheckout does not hold funds or execute settlement — it separates payment instructions from payment execution. Regulatory obligations still depend on your jurisdiction and business model, so production operators should obtain their own legal guidance.

Why OpenCheckout

Aspect	OpenCheckout	Platform-hosted processors
Deployment	Self-hosted on your server	Platform-hosted on their servers
Data ownership	You own all payment data	They own your payment data
Software transaction fee	None from OpenCheckout; providers may charge fees	Provider-specific
License	Open-source (AGPLv3)	Proprietary
Payment method	Any Open Payments wallet	Cards, bank transfers, their wallet
Wallet compatibility	Works with any compliant ASE	Locked to their ecosystem
API model	Checkout Sessions REST API	Provider-specific APIs

Key Features

• Checkout Sessions REST API — create checkout sessions, track payment progress, and return customers to your store when payment is complete
• Wallet-agnostic — any bank, digital wallet, or mobile money provider implementing Open Payments
• Cross-currency payments — customers pay in their currency; you receive in yours
• Interactive payment consent — customers approve payments at their own financial institution via GNAP
• Merchant dashboard — transaction history, API key management, webhook configuration
• Webhook delivery — HMAC-SHA256 signed events with automatic retries
• Cryptographic security — Ed25519 request signing, AES-256-GCM encryption at rest
• Simple deployment — Docker Compose with SQLite schema bootstrap included

How It Works

Step 1: Your backend creates a checkout session
  POST /api/checkout/sessions  →  { id, url, status: "open" }

Step 2: Redirect your customer to the checkout page
  https://checkout.yourdomain.com/pay/cs_abc123

Step 3: Customer enters their wallet address
  e.g., https://mybank.com/username

Step 4: OpenCheckout orchestrates the Open Payments flow
  incoming payment → quote → interactive grant → outgoing payment

Step 5: Customer is redirected to your success URL
  https://yourstore.com/order/123?session_id=cs_abc123&status=complete

Step 6: A webhook fires to your backend with full payment details

Quick Example

Create a $20.00 checkout session from your backend:

curl -X POST https://checkout.yourdomain.com/api/checkout/sessions \
  -H "Authorization: Bearer sk_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-456-unique-key" \
  -d '{
    "mode": "payment",
    "line_items": [{
      "price_data": {
        "currency": "usd",
        "product_data": { "name": "T-shirt", "description": "Cotton crew neck" },
        "unit_amount": 2000
      },
      "quantity": 1
    }],
    "success_url": "https://yourstore.com/order/456?session_id={CHECKOUT_SESSION_ID}",
    "cancel_url": "https://yourstore.com/cart",
    "metadata": { "order_id": "456" }
  }'

Response:

{
  "id": "cs_abc123xyz",
  "status": "open",
  "url": "https://checkout.yourdomain.com/pay/cs_abc123xyz",
  "amount_total": 2000,
  "currency": "usd",
  "mode": "payment",
  "expires_at": "2026-06-17T00:00:00Z",
  "created_at": "2026-06-16T00:00:00Z"
}

Redirect your customer to url. OpenCheckout handles everything else.

Open Payments Protocol

OpenCheckout is built on the Open Payments protocol — an open API standard maintained by the Interledger Foundation. The standard defines three server roles:

• Wallet Address Server — exposes public information about an Open Payments-enabled account
• Resource Server — exposes APIs for creating incoming payments, quotes, and outgoing payments
• Authorization Server — exposes GNAP-compliant APIs for obtaining grants

OpenCheckout acts as a client that orchestrates calls across all three servers. You do not need to understand the protocol internals — the SDK handles key management, request signing, grant negotiation, and hash verification automatically.

Who This Is For

• Developers and startups who want checkout software without an additional OpenCheckout transaction fee
• Merchants who want full control over their payment data and checkout experience
• Marketplace platforms that need to orchestrate payments between multiple parties
• Non-profits and open-source projects that want a payment solution aligned with their values
• Anyone with an Open Payments-enabled wallet who wants to receive payments on their website