Five implementation paths · static code guides

Add verified UPI checkout to your stack.

Choose your platform, create payment orders from a trusted backend, authenticate webhooks over raw bytes, and reconcile every ambiguous state.

Integration directory

Platform and framework guides

W 01

WordPress plugin

WooCommerce

Register a WooCommerce payment method, create the order server-side, redirect to hosted checkout, and verify signed callbacks before marking an order paid.

Guide covers

  • WC_Payment_Gateway class
  • Server-side create_order request
  • REST webhook route
  • Idempotent payment_complete
Open WooCommerce guide →
S 02

Commerce platform

Shopify

Choose between Shopify's approved payments-app programme and a transparent manual-payment workflow without claiming unsupported checkout access.

Guide covers

  • Supported-path decision
  • Shopify webhook HMAC
  • Hosted UPI instruction
  • Admin status reconciliation
Open Shopify guide →
JS 03

Backend framework

Node.js / Express

Create a typed payment client with timeouts and idempotency, expose a narrow checkout endpoint, and verify timestamped HMAC events from raw bytes.

Guide covers

  • Native fetch client
  • Integer-paise money model
  • express.raw webhook
  • Status reconciliation
Open Node.js / Express guide →
PY 04

Backend framework

Python / FastAPI

Use Decimal-safe request models, an async httpx client, raw FastAPI request bytes, hmac.compare_digest, and a transactional event consumer.

Guide covers

  • Pydantic request boundary
  • Async httpx integration
  • Raw-body HMAC
  • Database idempotency
Open Python / FastAPI guide →
PHP 05

Backend framework

PHP / Laravel

Build a Laravel service class, validate checkout requests, send authenticated API calls, verify hash_hmac signatures, and queue fulfilment after commit.

Guide covers

  • Config and secret storage
  • HTTP client service
  • Webhook controller
  • Queued fulfilment
Open PHP / Laravel guide →

Shared architecture

The framework changes. The payment invariants do not.

01

Secrets stay on the backend

The X-API-Key and webhook secret never enter browser JavaScript, a mobile package, Shopify theme code, WordPress markup, URLs, or analytics.

02

The application prices the order

Your server loads the cart and calculates the expected integer-paise total. A browser-supplied amount is never accepted as payment truth.

03

Redirects are presentation

The customer-facing redirect can display pending status, but only a verified server event or authenticated status response can drive fulfilment.

04

Retries are idempotent

Reuse one client_txn_id when a create request times out. Store a unique event key before applying a payment transition.

Canonical event flow

One state machine across every stack

All five guides implement the same trust model. The framework adapters change, but browser input remains untrusted and order state remains server-owned.

browser → merchant checkout endpoint
        → validate cart and amount
        → create_order (X-API-Key)
        ← hosted URL / QR / UPI intent

provider → signed merchant webhook
         → verify timestamp + raw body
         → match order + amount + currency
         → idempotent database transition
         → asynchronous fulfilment

Before writing framework code

Review credentials, request fields, and webhook semantics.

Read API overview