API reference

Understand the request, response and event contract.

A structured reference surface for authentication, idempotency, pagination, errors, payment orders, payouts and webhooks.

Discuss this solution

PayDrion API contract Explicit contract

Illustrative product operating view Request, response, error and event schemas in one reference.

Illustrative API workspaceTEST MODE

POST/v1/api-reference200

"reference": "pd_demo_48291", "capability": "authentication", "state": "versioned", "evidence": true

Resources Versioned

Errors Typed

Events Searchable

Versioned Typed Searchable

API reference

The integration should not depend on undocumented assumptions.

PayDrion documents field constraints, resource states, error categories and event relationships for implementation and support.

Resource schemas

See required fields, constraints and example payloads for each operation.

Error taxonomy

Handle validation, authentication, eligibility, processing and rate-limit responses.

Event catalogue

Map webhook types to the records and states they represent.

API reference

The integration should not depend on undocumented assumptions.

PayDrion documents field constraints, resource states, error categories and event relationships for implementation and support.

API referenceDedicated product layer · shared PayDrion evidence model

PayDrion product architecture Explicit contract

Authentication See required fields, constraints and example payloads for each operation.

Versioned

Resources Handle validation, authentication, eligibility, processing and rate-limit responses.

Typed

Errors Map webhook types to the records and states they represent.

Searchable

Events See required fields, constraints and example payloads for each operation.

Versioned

PayDrion evidence lineRequest · decision · partner reference · signed event · operator action

Test-mode examples

Stable identifiers. Explicit states. Safer retries.

The examples demonstrate the intended integration pattern; endpoint availability and credentials follow successful onboarding.

Bearer credentials scoped by environment
Idempotency on money-moving requests
Signed webhooks as asynchronous evidence

PayDrion test environment Example ready

POST /v1/payment-orders

curl --request POST https://api.paydrion.com/v1/payment-orders \
  --header "Authorization: Bearer <test_key>" \
  --header "Idempotency-Key: order_20481" \
  --header "Content-Type: application/json" \
  --data '{
    "amount": 249900,
    "currency": "INR",
    "reference": "ORDER-20481",
    "customer": {"email": "customer@example.com"}
  }'

Questions

Practical answers before implementation.

Commercial and technical details are confirmed for the specific entity, use case and approved programme.

How does implementation begin?+

PayDrion first maps your business model, transaction flow, expected volumes, risk profile and required payment rails. An implementation plan and test credentials follow successful onboarding.

Can this be enabled for every business?+

Availability, limits, pricing and settlement timelines depend on onboarding, use case, bank or network partner approval, and applicable regulation.

How are transaction states confirmed?+

Use the synchronous API response for immediate context, then rely on signed webhooks and server-side status verification as the operational source of truth.

Understand the request, response and event contract.

The integration should not depend on undocumented assumptions.

Resource schemas

Error taxonomy

Event catalogue

The integration should not depend on undocumented assumptions.

Stable identifiers. Explicit states. Safer retries.

Practical answers before implementation.

Related PayDrion capabilities.

Payment APIs that behave consistently under pressure.

Choose hosted checkout, embedded UI or direct API orchestration.

Practical guides for reliable payment operations.