Skip to main content
createOrder() is the server-side operation used to start a Universal Payment Gateway checkout. It creates a provider-neutral payment session from an available payment method and returns the checkout instructions for that gateway. The integration rules on this page apply to every AvraAPI SDK. Laravel 1.2.0 uses AvraAPI::payment() and Node.js SDK 1.2.0 uses client.payment() with the same typed payment options and server-only safety boundary.
Create a pending order in your own database before starting checkout. A UPG session is not proof that a customer paid. Confirm payment later through Payment Response & Completion.

The safe initiation flow

  1. Your backend creates a unique pending order.
  2. Your server checks availability() and selects one returned method.
  3. Your server calls createOrder().
  4. Your server stores the returned completionContext against that pending order.
  5. Your browser receives only the public checkout instructions and follows the supported checkout mode.

1. Choose a GatewayCode from availability

Do not accept a gateway name from an untrusted browser request without checking it against the current server-side availability result. A method can become unavailable when the project is paused, its UPG slot is released, its configuration is disabled, or the selected origin is not allowed.
The SDK recognises payhere, marxpay, directpay, payplus, webxpay, koko, onepay, and stripe. Recognition is not entitlement: availability() is the source of truth for what this project can use now.

2. Choose the CheckoutMode

Use the mode returned by availability for the chosen gateway. Do not invent a mode because a provider supports another style outside AvraAPI.

3. Set order details

orderId, items, amount, and currency are required. Use an order ID that is unique in your merchant system. Pass money as a positive decimal string with at most two decimal places; never calculate or serialize money as a floating-point value.
Calculate the final amount on your backend from trusted product and pricing data. Never accept the order total from browser JavaScript.

4. Provide the customer object

The SDK requires first_name, last_name, email, phone, address, city, and country. You may provide address_line_1 and address_line_2 instead of address; the SDK combines the non-empty lines into the required address value.
Collect and validate this data in your application. Payment Elements can help render a customer form, but it does not replace your server-side validation.

5. Set trusted return, cancel, and webhook URLs

Build URLs in your backend from registered configuration. One shared completion handler or controller can serve every gateway when its gateway-scoped callback and return routes dispatch safely. Do not copy a return URL, webhook URL, or host name from a buyer request.
A return URL improves the buyer experience; it does not prove payment. Your gateway-scoped callback or return route can enter one shared completion handler, which must still call completePayment() in your backend. Use the exact configured URL where a gateway requires it; for example, Stripe requires the configured Success Return URL and Dashboard webhook URL.

6. Optional: set merchantDomain

merchantDomain identifies the configured domain for method discovery and origin policy checks. It is optional. When you omit it, AvraAPI resolves the configured project default. Supply it when your checkout uses a specific registered host.
Origin rules are provider-specific. Do not assume that an allowed domain rule for one gateway automatically applies to every other gateway.

7. Optional: pass providerOptions

providerOptions holds gateway-specific, non-secret checkout options. It is optional; keep it empty for the common flow. Add only values documented for the selected gateway in Gateway-wise Functions; never put API keys, gateway secrets, signing secrets, or buyer-controlled arbitrary data here.

8. Optional: select the gateway environment

Gateway environment selects the vaulted Sandbox or Production profile. It is separate from your AvraAPI client environment and must stay server-side.

Configure a default environment in PHP or Laravel

For one common environment across all gateways, this is enough:

Override selected gateways in PHP or Laravel

Use APIX_PAYMENT_GATEWAY_ENV_OVERRIDES only when one or more gateways need a different environment from the default. The format is a comma-separated gateway:sandbox or gateway:production list.
The all-sandbox override example is explicit but redundant because the default already selects Sandbox. A practical mixed deployment could set a default to Production and override only the gateways still being tested.

Override an environment for one order

You can also select a gateway environment for one server-side order. This is optional and takes priority over the configured default and override list. Never let browser input select it.

9. Call createOrder()

Bring the required and optional options together with one named-argument call. Omit optional named arguments when you do not need them.

Store the PaymentSession correctly

PaymentSession contains gateway, mode, status, expiresAt, checkout, requestId, flow, binding, verification, and completionContext. Store the completionContext with the pending merchant order before responding to the browser. It binds future provider evidence to this payment session.
Never send completionContext to a browser. Never put it in a redirect URL, frontend state store, analytics event, application log, cache entry, queue payload, or support screenshot.

Return only public checkout instructions

Your frontend normally needs the gateway, mode, expiry, and checkout object. Keep the server-side completion data in your own order record.
checkout is gateway- and mode-specific. Pass it unchanged to the supported browser handoff; do not attempt to construct provider checkout instructions yourself. Continue with Payment Response & Completion.
Last modified on October 1, 2026