RL//PAYENTERPRISE PAYMENT COMMAND
P100--:--:--OVERVIEW
LIVE
HYPERSWITCH • QRIS • STRIPE • MIDTRANS • XENDIT • PAYPAL • PAYMENT INTENTS • DYNAMIC ROUTING • WEBHOOKS • REFUNDS • SETTLEMENT • IDEMPOTENCY • TOKENIZATION • FRAUD CONTROLS • RECONCILIATION •
ROBERTO MULTI-PROVIDER PAYMENT CONTROL PLANE
HYPERSWITCH / UNIFIED CHECKOUT / LIVE ORCHESTRATION

ONEORCHESTRATOR.EVERY PAYMENT RAIL.

Hyperswitch unifies QRIS, Stripe, Midtrans, Xendit, and PayPal behind one payment contract with routing, webhook normalization, refund control, settlement visibility, and security policy.

5Payment rails
—Payment methods
—API routes
—Runtime
01

Unified payment architecture

One request contract, policy-driven connector selection, and a normalized post-payment lifecycle.

CLIENTSWeb · Mobile · POS · Marketplace
→
→
→
POST-PAYMENTWebhook · Refund · Settlement · Ledger
02

Live payment orchestration

Create a simulated enterprise payment intent and inspect how the routing engine selects a connector.

CREATE PAYMENT INTENTLIVE API
ORCHESTRATION RESULTREADY
Create a payment intent to see routing, next action, idempotency, and normalized status.
03

Transaction security

Security controls are applied at the orchestration, provider, webhook, and operational layers.

NO RAW CARD STORAGE

Use hosted fields or tokenized provider data; never expose secret keys in the browser.

IDEMPOTENCY

Unique request keys prevent accidental duplicate payment and refund creation.

WEBHOOK VERIFICATION

Verify provider signatures or callback tokens before changing order state.

LEAST PRIVILEGE

Separate payment, refund, settlement, and reconciliation permissions.

04

Combined source vault

Original Hyperswitch and GitHub Home source archives are retained with SHA-256 verification and Cloudflare-safe chunking.

Reading source manifest…
P200

Documentation

Unified payment API, webhook contract, connector policy, deployment, and security guidance.

QUICK START / EDGE DEMOHTTP
  1. Upload this ZIP to Cloudflare Pages Direct Upload.
  2. Optionally bind PAYMENT_DB (D1) and configure production secrets.
  3. Create an intent through POST /api/payment-intents.
  4. Confirm it, receive a normalized webhook, then refund or reconcile settlement.
curl -X POST https://YOUR-PROJECT.pages.dev/api/payment-intents \\
  -H "content-type: application/json" \\
  -H "idempotency-key: order-1001" \\
  -d '{"amount":150000,"currency":"IDR","method":"qris","country":"ID"}'
PAYMENT API ROUTESLOADING
MethodPathPolicyDescription
PAYMENT CONFIGURATION BROWSERCONFIG
Loading configuration…
PRODUCTION BOUNDARYIMPORTANT
This Cloudflare runtime is a functional orchestration simulator and documentation surface. Real charges require provider merchant accounts, credentials, PCI-appropriate collection, provider SDKs or hosted checkout, signature verification, persistent storage, and deployment of Hyperswitch or its managed service.
P300

GitHub

Official Hyperswitch source plus the retained source vault used to construct this enterprise payment portfolio.

Loading repository metadata…
SOURCE VAULT POLICYSHA-256

The original uploaded Hyperswitch ZIP is stored unchanged, split only into sub-25 MiB files for Cloudflare Pages. Reassembly scripts restore the byte-identical archive.

Open source manifest ↗
P310

Hyperswitch

The unified orchestration layer that owns payment intent lifecycle, connector selection, retries, webhook fan-out, and post-payment operations.

HS
PAYMENT ORCHESTRATION

Juspay Hyperswitch

Expose one API while keeping provider choice flexible. Routing can consider country, currency, payment method, connector health, cost, and business rules.

GitHub repository ↗
UNIFIED PAYMENT API

Normalize intent, confirmation, capture, cancellation, and refund operations.

INTELLIGENT ROUTING

Select providers by rules, availability, geography, method, or optimization policy.

RETRY + FALLBACK

Recover from eligible failures without coupling application code to one PSP.

WEBHOOK FAN-OUT

Translate provider lifecycle events into one merchant-facing event model.

ROUTING BLUEPRINTTOML
Loading…
P400

QRIS

Indonesia’s national QR payment standard, presented through one dynamic payment intent and provider-neutral status model.

QR
INDONESIA QR PAYMENT RAIL

QRIS

A customer scans a merchant-presented QR code with a compatible banking or e-wallet application. The application must rely on verified provider status or webhook notification before fulfillment.

DEMO QR PAYLOADSIMULATED

Visual demo only. Production QR payloads must be generated by an authorized payment provider.

QRIS ROUTINGMIDTRANS / XENDIT
Methodqris
CurrencyIDR
CountryID
PrimaryXendit
FallbackMidtrans
FulfillmentOnly after verified paid/settlement state
NORMALIZED LIFECYCLEASYNC
REQUIRES_ACTIONQR payload created
→
CUSTOMER_SCANBank or wallet confirms
→
PROCESSINGProvider validates payment
→
SUCCEEDEDVerified webhook received
→
SETTLEDFunds reconciled
P500

Stripe

Global card and payment-method connector using PaymentIntent-style lifecycle, asynchronous status, webhooks, and full or partial refunds.

S
GLOBAL PAYMENT PROCESSOR

Stripe

Use one payment object per order or session, handle additional authentication when required, and treat webhook status as the durable source for asynchronous outcomes.

Official documentation ↗
PAYMENT INTENTS

Track a payment through creation, confirmation, authentication, capture, and final status.

WEBHOOK EVENTS

React to success, failure, disputes, refunds, and delayed payment methods.

IDEMPOTENT WRITES

Attach a stable key to retried create and refund requests.

REFUNDS

Issue full or partial refunds against the original charge or payment intent.

P600

Midtrans

Indonesia-focused provider for QRIS and local payment methods with asynchronous notifications and settlement-oriented transaction states.

M
INDONESIA PAYMENT GATEWAY

Midtrans

Route eligible Indonesian transactions through Midtrans, verify notification authenticity, query transaction status when needed, and map provider states into the normalized platform lifecycle.

Official documentation ↗
QRIS + GOPAY

Dynamic or supported static QR payment flows for compatible applications.

HTTP NOTIFICATION

Receive transaction state changes on the merchant backend.

STATUS MAPPING

Map pending, settlement, deny, cancel, expire, and refund outcomes.

REFUND ELIGIBILITY

Apply method-specific refund rules rather than assuming every rail is refundable.

P700

Xendit

Regional payment connector for QRIS and local Southeast Asian rails with callback-token verification and split settlement options.

X
SOUTHEAST ASIA PAYMENT INFRASTRUCTURE

Xendit

Use Xendit as a primary QRIS/local-rail connector, verify the callback token on every webhook, and reconcile provider settlement reports against internal payment records.

Official documentation ↗
QRIS

Accept QRIS transactions through supported banking and e-wallet applications.

CALLBACK TOKEN

Reject webhook notifications that do not carry the expected verification token.

LOCAL METHODS

Model virtual accounts, e-wallets, cards, and other enabled regional methods.

SPLIT SETTLEMENT

Blueprint for routing proceeds across platform accounts or sub-merchants.

P800

PayPal

Wallet and checkout connector using order authorization/capture, webhook notifications, and capture-based refunds.

P
GLOBAL WALLET + CHECKOUT

PayPal

Create an order, redirect the customer for approval when needed, capture the payment, subscribe to capture events, and refund using the original capture identifier.

Official documentation ↗
ORDER + CAPTURE

Separate customer approval from the final capture operation.

WEBHOOKS

Track completed, denied, reversed, pending, and refunded events.

REFUND CAPTURE

Issue full or partial refunds using the original capture ID.

ASYNC OUTCOMES

Do not rely solely on browser redirects to determine fulfillment.

P900

Payment Flow

A complete intent-to-settlement lifecycle with routing, customer action, provider processing, normalized webhook, and ledger update.

ENTERPRISE PAYMENT SEQUENCE8 STAGES
01 / CREATE

Payment Intent

Validate amount, currency, order reference, customer, and idempotency key.

02 / ROUTE

Connector Policy

Hyperswitch selects an eligible provider using method, region, health, and business rules.

03 / ACTION

Customer Step

Scan QRIS, complete 3DS, approve PayPal, or follow provider instructions.

04 / PROCESS

Provider Result

Provider moves the transaction through pending, processing, success, or failure.

05 / WEBHOOK

Verified Event

Signature or callback token is checked before normalized order state changes.

06 / FULFILL

Order Delivery

Fulfillment runs only after a trusted terminal payment state.

07 / REFUND

Post-Payment

Full or partial refund respects provider and payment-method eligibility.

08 / SETTLE

Reconciliation

Match provider settlement records, fees, refunds, and net merchant proceeds.

PAYMENT FLOW LABLIVE
PAYMENT STATEREADY
Run the sequence to inspect each normalized state.
RECENT NORMALIZED WEBHOOK EVENTS0 EVENTS
No webhook events yet.
P910

Refund

Provider-neutral full and partial refunds with idempotency, eligibility checks, normalized status, and auditable references.

CREATE REFUNDLIVE API

Create a payment in Payment Flow first, then use its payment ID here.

REFUND RESPONSEREADY
Refund result will appear here.
REFUND LEDGER0 RECORDS
Refund IDPaymentProviderAmountStatusCreated
No refunds recorded.
P920

Settlement

Reconcile gross payments, provider fees, refunds, and net merchant proceeds across every connector.

RECONCILIATION CONTROLLIVE API
Three-way match

Compare internal payment ledger, normalized webhook events, and provider settlement/report data.

SETTLEMENT SUMMARYREADY
—Gross
—Fees
—Refunds
—Net
Run reconciliation to generate a settlement batch.
SETTLEMENT BATCHESLOADING
BatchProviderCurrencyGrossFeesRefundsNetStatus