Aegis Rails
DocsTalk to Us
01 / GATEWAY

ONE ENTRY POINT. MANY POSSIBLE PATHS.

A consistent payment interface designed to separate your integration from the complexity of downstream processing.

Talk to Aegis RailsFor Developers
HOW IT WORKS

ONE API. A KNOWN LIFECYCLE.

01 / API LIFECYCLE

A payment is a stateful object.

Create, authenticate, authorise, capture, refund — each step is an explicit API call or event against the same payment object, regardless of which connector processes it.

REQUESTILLUSTRATIVE
POST /v1/payments
{
  "amount": 12500,
  "currency": "USD",
  "capture_method": "manual",
  "payment_method": { "type": "card", "token": "tok_…" }
}
02 / PAYMENT STATES

States are the same across every connector.

Connectors report different raw statuses. The gateway maps them onto one state model so merchant systems are built once.

STATE MODELILLUSTRATIVE
  1. createdobject exists
  2. requires_action3DS challenge
  3. authorisedfunds held
  4. capturedfunds requested
  5. refunded / voidedreversed
03 / AUTHENTICATION

Authentication is a step, not a side flow.

When the issuer or a control requires 3DS, the payment moves to requires_action with a challenge URL. The outcome — frictionless, challenged, failed — is stored on the payment and available to routing.

RESPONSE / REQUIRES_ACTIONILLUSTRATIVE
{
  "status": "requires_action",
  "next_action": {
    "type": "3ds_challenge",
    "url": "https://…/challenge"
  }
}
04 / CAPTURE / REFUND

Capture and refund on the original payment.

Partial capture, multiple partial refunds and voids before capture are operations on the same object, so balances stay consistent without merchant-side bookkeeping.

OPERATIONSILLUSTRATIVE
POST /v1/payments/pay_ag_8J29L/capture   { "amount": 10000 }
→ status: captured   captured: 100.00  remaining: 0.00

POST /v1/payments/pay_ag_8J29L/refunds   { "amount": 2500 }
→ refund: re_ag_02F  status: pending
NEXT STEP

BUILD THE RIGHT
PAYMENT PATH.

Let's discuss the infrastructure your business needs.

Talk to Aegis Rails