Introduction

Creates a new checkout session for hosted or embedded checkout. Returns a session with a URL to redirect customers for payment.

Retrieves an existing checkout session by ID. Returns full session data including clientSecret.

Updates an open checkout session. Immutable fields (mode, uiMode, submitType, currency, expiresAfterMinutes) cannot be changed after creation.

Expires an open checkout session. Expired sessions cannot be used for payment.

Lists customers with search and pagination. Returns only essential fields: id, createdAt, name, phone, email, and latestPaymentMethod. Search supports customer ID, name, email, or phone (supports comma-separated terms).

Creates a new customer record. At least one contact method (email or phone) is required. Customers are environment-specific (test vs live database).

Retrieves customer lifecycle information (id, type, name, email, phone, address, metadata). Response shape is identical to the `customer.*` webhook payload. For transaction counts + payment methods, call `GET /customers/:id/stats`.

Lists payment links with filtering, pagination, and search. Features: - Filter by active status - Search by product name, description, or unit label - Filter by amount (equal, between, greater, less) - Filter by date (last period, equal, between, after, before) - Pagination support

Creates a new payment link — a shareable URL you can send to customers. Features: - Supports multiple line items with adjustable quantities - Custom fields for collecting additional customer information - After-completion settings (redirect or hosted confirmation) - Automatic amount calculation from line items - Validates currency consistency across line items

Retrieves a payment link with all related data including: - Line items with prices and products - Custom fields with dropdown options - After-completion settings

Partially updates an existing payment link. Only provided fields will be updated. Features: - Partial updates: only send fields you want to update - Updates line items with adjustable quantities (if provided, replaces all existing line items) - Updates custom fields (if provided, replaces all existing custom fields) - Updates after-completion settings (if provided, replaces existing settings) - Recalculates amount from line items when line items are updated - Validates currency consistency across line items when line items are updated Notes: - If `lineItems` is provided, all existing line items are replaced - If `customFields` is provided, all existing custom fields are replaced - If `customFields` is an empty array, all custom fields are removed - `expiresAt` can be set to `null` to remove expiration

Retrieves product information including all associated prices. Response shape is identical to the `product.*` webhook payload. For per-price usage counts, call `GET /products/:id/stats`.

Updates product information. Can update product data fields, default price, and image. - The `defaultPrice` field should be the ID of the Price object to set as the default price for this product - The `image` field should be a URL string (use the `/upload-url` endpoint to get a one-time upload URL first)

Deletes a product and cascade-deletes all of its prices in one transaction. Fails if any of the product's prices have ever been referenced by a line item — in that case the product must be archived instead.

Lists products with search and filters. Supports: - Active filter (`active=true/false`) - Metadata filter (JSON string) - Search in `name`, `description`, and `unitLabel` fields - Pagination

Creates a new product. Optionally includes: - An image URL (use the `/upload-url` endpoint to get a one-time upload URL first) - A default price object which will be set as the default price for this product

Creates a new Price for an existing Product.

Updates the specified price by setting the values of the parameters passed. Any parameters not provided are left unchanged.

Deletes a price. Only prices that have never been referenced by a line item can be deleted — once a price has been used in any checkout session or payment link, archive it instead. If the price is set as the default price for a product, the default price reference will be cleared.

Lists refunds with optional filters for charge and pagination.

Creates a full or partial refund for a successful charge. Target: provide EXACTLY ONE of `chargeId` or `paymentIntentId`. When `paymentIntentId` is supplied the server resolves it to the unique succeeded charge under that intent; the request is rejected if the intent has zero or multiple succeeded charges. Features: - Full or partial refunds - Ledger reversal (double-entry bookkeeping) - Balance updates (debits available funds) - Updates `charge.amountRefunded` - Updates `paymentIntent.amountRefunded` Refund behaviour: - Hits available balance immediately (no hold period) - Creates negative balance transactions - Reverses the original charge's ledger entries - Platform keeps fees (business decision)

Retrieves a refund with all details including ledger info.

A Balance Transaction records every movement of money in or out of your xpay balance: successful charges, refunds, payouts, processing fees, and adjustments. Each Balance Transaction links back to its `source` (the Charge, Refund, or Payout that produced it) and breaks down `gross`, `fee`, and `net` amounts. Use Balance Transactions to reconcile what was paid into your account against what was settled to your bank.

A Charge represents a single attempt to move money from a customer's payment method to your account. It records what was paid, by whom, through which processor, and the final outcome: `succeeded`, `failed`, or `refunded`. A single PaymentIntent may produce multiple Charges if earlier attempts fail; only the most recent successful Charge actually moves funds, and any subsequent Refunds reference it directly.

A Checkout Session represents your customer's session as they pay on an xpay-hosted checkout page. Create a new Session each time a customer begins a checkout: attach line items, customer details, or a PaymentIntent, then redirect the customer to the Session's `url` to begin payment. As the customer progresses, the Session's `status` and `paymentStatus` update; once payment succeeds, the Session contains references to the resulting Customer and PaymentIntent. Sessions expire 24 hours after creation if not completed.

A Coupon defines a reusable discount you can apply to Checkout Sessions and PaymentIntents. Coupons can grant either a percentage off (`percentOff`) or a fixed amount off (`amountOff`), and can apply once, forever, or repeating for a number of billing cycles. You can also cap how many times a Coupon may be redeemed and when it expires. Coupons are the reusable template. Each concrete application of a Coupon to a customer's purchase is recorded as a Discount. To give customers a redeemable code (e.g. `SUMMER25`) instead of applying the Coupon directly, create one or more Promotion Codes that map to this Coupon — a single Coupon can have many Promotion Codes, each with its own per-code restrictions. You receive `coupon.*` and `promotion_code.*` webhook events for each as they are created or changed.

A Customer represents a buyer you do business with. Use Customers to save payment methods for reuse, track lifetime spend, attach metadata for your CRM, and group related Charges, Refunds, and Checkout Sessions under a single record. You can identify a Customer by their email or by a stable external ID from your own system and reference them on any future payment.

A Discount records a single application of a Coupon to a specific Checkout Session, PaymentIntent, or Customer. Where a Coupon is the reusable template, a Discount captures the concrete redemption: which Coupon was applied, when it became active, when it expires, and (when applicable) which Promotion Code the customer entered to claim it.

A PaymentIntent tracks the full lifecycle of collecting one payment from your customer: from creation, through authorization and 3-D Secure, to capture and final outcome. We recommend creating one PaymentIntent per order: you can inspect its history of Charge attempts, watch its `status` as it transitions, and reference the successful Charge it ultimately produces. PaymentIntents are the object that the hosted Checkout and xpay.js drive on the client to complete a payment.

A Payment Link is a shareable URL you can send to a customer to collect a single payment or set up a subscription, without writing any checkout code. Open the URL in any browser and we render the hosted checkout, collect payment details, and process the payment. Use Payment Links for one-off invoices, social-media checkout, in-person QR codes, or anywhere you need a checkout page without integrating the SDK.

A Price defines what a Product costs: the unit amount, currency, and (for subscriptions) billing interval. A single Product can have many Prices, letting you offer the same item in multiple currencies, tiers, or billing models without duplicating your catalog. Reference a Price by ID when creating Checkout Sessions, Payment Links, or line items, and the customer is charged according to what the Price defines.

A Product represents a good or service you sell. Products carry only descriptive information (name, description, images), while their pricing is described separately by Price objects. A single Product can have many Prices: for example, the same digital course offered in EGP and USD, or at different tiers. Use Products to model your catalog and Prices to model how each is sold.

A Promotion Code is a customer-facing alphanumeric code (for example `SUMMER25`) that maps to a single Coupon. One Coupon can have many Promotion Codes, letting you run different campaigns (email vs. social, customer-specific codes, regional codes, …) against the same underlying discount. Customers enter the code at checkout to redeem the Coupon's discount. Promotion Codes can carry their own restrictions on top of the Coupon — a per-code redemption cap, an expiry date, or a binding to a specific Customer. You receive `promotion_code.created` and `promotion_code.updated` webhook events whenever a code is created or modified.

A Refund returns funds from a successful Charge back to the customer's original payment method. Refunds can be full or partial, and a single Charge can be refunded multiple times up to its original amount. The Refund's `status` reflects the processor's progress as the money makes its way back: `pending` while in flight, `succeeded` once the funds have been returned, or `failed` if the processor rejected the request.