Skip to main content
This guide is the fastest complete way to add Universal Payment Gateway (UPG) checkout to a website. It uses one server-side SDK flow for every payment gateway your project is allowed to use, while Payment Elements provides the optional browser form and method selector. You do not build separate checkout logic for PayHere, OnePay, DirectPay, Stripe, or another configured gateway. Your server asks AvraAPI what is available, creates one payment session for the buyer’s selected available method, and completes the payment only after verified provider evidence arrives.
Keep the SDK, Client ID, Client Secret, gateway environment, completionContext, and payment completion logic on your backend. Payment Elements receives only browser-safe availability data and public checkout instructions.

What you will build

/payments/checkout-session used in this guide is an example URL in your own application. It is not an AvraAPI endpoint, SDK route, or required file name. Use the route structure that fits your application.

Before you start

  1. Create an AvraAPI project and keep its Client ID and Client Secret on your server.
  2. Connect the project to an active Workspace UPG slot.
  3. Configure at least one gateway profile in the Gateway Vault and make sure the intended domain is allowed.
  4. Create one shared payment-completion handler and expose its public HTTPS callback and return routes.
  5. Create a database record or equivalent durable store for your own pending orders. It must retain the gateway, amount, currency, and server-only completionContext.

One completion handler, not one file per gateway

UPG has one universal server-side completion operation: completePayment(). You can keep the integration to two application components: a checkout-session handler and a shared payment-completion handler. Payment providers do not send the same HTTP payload. For example, Stripe sends a signed raw webhook body, DirectPay sends a raw body plus an HMAC authorization header, and PayHere posts form fields. Use one of the following server-controlled routing styles. In both cases, every URL reaches the same completion-handler file or controller.
The route or parameter is configured by your server or in the provider dashboard; it is not selected by the buyer. It is a dispatch hint, not a secret or payment proof. The provider payload wrapper and the stored signed completionContext still perform the real verification.
Do not use one identical URL for every provider unless your handler has a deterministic, reviewed gateway-dispatch design. The PHP SDK does not provide an automatic all-gateway payload detector.

The quick flow

1

Check availability

Your backend calls availability().
2

Display methods

Payment Elements displays only the returned available methods.
3

Customer input

The buyer selects a method and enters customer details.
4

Create session

Your backend checkout endpoint validates the method and calls createOrder().
5

Launch checkout

The browser launches the returned provider checkout.
6

Receive callback

The provider callback or trusted return reaches your shared completion handler.
7

Verify and fulfil

Your backend calls completePayment(), verifies success, and fulfils the order once.

The three UPG SDK calls

Every UPG checkout follows the same server-side sequence across the PHP, Laravel, and Node.js SDKs. Laravel 1.2.0 exposes the verified payment service through AvraAPI::payment(); Node.js SDK 1.2.0 exposes it through client.payment(). The full implementation guide below shows how to combine these calls with your own checkout page, order storage, and fulfilment code.

1. Discover available methods with availability()

Call availability() on your backend before showing payment choices. It returns only methods that the project, active UPG slot, configured gateway profiles, environment, and merchant domain currently allow. AvraAPI SDK call — real method
Never trust a gateway or mode merely because the browser posts it. Validate the selected pair against a fresh availability() result again when creating the order.

2. Prepare checkout with createOrder()

Call createOrder() only after your server has calculated the order amount, currency, item description, URLs, and selected available gateway/mode. It returns a short-lived PaymentSession with public checkout instructions and a server-only completionContext. AvraAPI SDK call — real method

3. Verify and finish with completePayment()

Call completePayment() only from your backend after a provider callback or supported return reaches your shared completion handler. It returns the safe, normalized PaymentCompletionResult in short() mode by default. Passing PaymentResponseOptions::short() explicitly is optional; it can make the intended production response mode clearer in your code. AvraAPI SDK call — real method
The typed SDK result — real properties
The SDK maps the API’s data object into this PaymentCompletionResult. There is no $result->data property. For the raw API envelope and the short(), full(), and include() response contracts, see Payment Response & Completion.

Handle every payment outcome

verified means that the provider evidence and signed completion context were accepted. It does not mean the payment succeeded. A signed callback can validly report a failed, cancelled, pending, or unknown payment. Your application code — handle the typed SDK result. The order methods below are examples of methods you implement in your own application; they are not AvraAPI SDK methods.
The raw AvraAPI transport response can have success: true while data.payment_status is failed, cancelled, pending, or unknown. success describes the completion request; payment_status describes the payment outcome.

Complete development guideline

1. Initialize the SDK

Keep the project Client ID and Client Secret in server environment variables. Never initialize this client in a browser bundle.

2. Add the checkout page with Payment Elements

Payment Elements is the recommended quick-start UI because it renders the customer form, shows only server-discovered payment methods, handles unavailable states, and launches the correct public checkout presentation. The PHP page below obtains browser-safe availability data on the server. It does not expose the SDK credentials, Vault configuration, Workspace data, or gateway secrets. Your application code — this page includes one real availability() SDK call. Replace the markup, styling, product display, and /payments/checkout-session URL with your own application design.
The browser sends the selected gateway, mode, customer fields, and non-secret providerOptions to your checkout-session endpoint. Your server must validate the gateway/mode again against a fresh availability() result. Browser input is only a request, never permission to use a gateway.
For styling, custom labels, DirectPay container placement, events, and unavailable-state behaviour, see Payment Elements.

3. Create the payment session on your server

Your backend checkout endpoint must calculate the order amount from trusted server data, validate the chosen gateway and mode against availability, create the session, and persist completionContext with your pending order. Do not accept item prices, currency, URLs, or gateway environment from the browser. Combined reference — your application code plus real AvraAPI SDK calls. Replace only the order-storage and product-pricing portions marked in the code; retain the availability validation and createOrder() structure.

What Payment Elements does next

After your endpoint returns the public session, Payment Elements chooses the correct presentation automatically: For a fully custom browser UI without Payment Elements, use Redirect Checkout or In-page Checkout. Those pages document the exact SDK-only handoff for each public checkout type.

4. Complete the payment in the shared handler

The shared handler receives the gateway from its server-defined route or query parameter, then loads the exact pending merchant order and its saved completionContext. It uses the matching gateway-specific provider callback payload wrapper before calling completePayment(). Do not fulfil an order from a browser redirect, overlay event, or frontend “success” message. Combined reference — your application code plus the real completePayment() SDK call. The example below uses the simple query-parameter routing style. With route-based routing, obtain the same gateway value from your framework route parameter instead.
findPendingOrderFromProviderCallback(), buildGatewaySpecificProviderPayload(), and markOrderPaidAndFulfilOnce() represent your own application’s order persistence, gateway dispatch, and fulfilment logic. They are deliberately not SDK methods. The SDK call itself is completePayment(). The typed SDK response — an example short() result represented as an array
This is a server-side representation of the real PaymentCompletionResult properties, not a second API response and not data to return to the buyer. Gateway-specific values and reconciliation metadata vary by provider and completion path. Use Payment Response & Completion for the response contract, PaymentResponseOptions::short(), full(), include(), reconciliation rules, and provider payload requirements.

Quick Setup safety checklist

  • Run availability() on the server and validate the buyer’s selected gateway/mode against it again during session creation.
  • Route each provider’s configured callback/return URL into one shared completion handler with a server-defined gateway identifier; never guess the provider from an untrusted browser value.
  • Calculate product, price, currency, callback URLs, merchant domain, and gateway environment on the server.
  • Persist completionContext only with the pending merchant order; never return or log it.
  • Return only gateway, mode, expiry, request ID, and checkout data to the browser.
  • Treat Elements and provider browser events as UI signals, not payment proof.
  • Use completePayment() and fulfil only a verified PaymentStatus::Succeeded result.
  • Make payment completion and fulfilment idempotent because provider callbacks can be delivered more than once.

Download sample code files

Downloadable, reviewed sample projects are being prepared. The packages below will be published only after their gateway contract tests and framework examples are complete.

PHP sample

Coming soon — a complete PHP checkout and shared completion-handler ZIP.

Laravel sample

Laravel SDK 1.2.0 is supported above. A downloadable controller, routes, jobs, and checkout example ZIP will be added separately.

Node.js sample

Use the released Node.js server-side availability, create-order, and completion examples on this page.

Next steps

  • Project Slots — understand why a project needs an active UPG slot.
  • Gateway Vault — configure provider credentials safely.
  • Advanced Setup — use custom checkout flows, response options, gateway environments, and advanced provider behaviour.
  • Payment Elements — customise fields, methods, events, and unavailable states.
Last modified on October 1, 2026