R
Docs
API Documentation

Payments API

The payment-side endpoints that complement the orders flow.

1 min read Updated 5/28/2026developer

Create a payment intent

POST /api/public/[tenantId]/payment-intent — the orders + payment one-shot endpoint. Atomically:

  1. Validates + prices the cart
  2. Resolves any coupon + gift-card code
  3. Creates the Order in DB (status pending, paymentStatus pending)
  4. Creates a Stripe PaymentIntent
  5. Returns { orderId, orderNumber, clientSecret }

Front-end then mounts Stripe Elements with the clientSecret and confirms the payment.

Available payment methods

Per-tenant configuration at GET /api/public/[tenantId]/payment-methods. Returns booleans for cards, Apple Pay, Google Pay, Klarna, PayPal, Swish, and regional methods. Front-end uses this to decide which buttons to render at checkout.

Refunds

Refunds are usually triggered automatically by the cancellation flow (see Orders API). For partial / manual refunds, super-admins use POST /api/admin/escrow/refunds:

Shell
curl -X POST \
  -H "Content-Type: application/json" \
  -b admin-cookies.txt \
  -d '{ "orderId": "ord_abc123", "amount": 5.00, "reason": "missing-side" }' \
  https://api.restora360.com/api/admin/escrow/refunds

Refunds run through Stripe directly; Restora 360's ledger updates automatically when Stripe confirms.

Escrow status

Every paid order moves through escrow states:

  • held — funds in Stripe pending fulfillment
  • released — payout scheduled (delivered + configured delay elapsed)
  • refunded — fully refunded
  • partial_refund — partially refunded
  • void — pre-acceptance cancel

Query via GET /api/tenant/[tenantId]/orders/[orderId]/escrow.

Related articles