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
- Create an AvraAPI project and keep its Client ID and Client Secret on your server.
- Connect the project to an active Workspace UPG slot.
- Configure at least one gateway profile in the Gateway Vault and make sure the intended domain is allowed.
- Create one shared payment-completion handler and expose its public HTTPS callback and return routes.
- 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.
- Routes — recommended
- Parameters — simple PHP
{gateway} route value is selected by the server route and must be checked against your enabled gateway allow-list before it reaches the handler.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 throughAvraAPI::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
- PHP
- Laravel
- Node.js
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
- PHP
- Laravel
- Node.js
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
- PHP
- Laravel
- Node.js
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.
- PHP
- Laravel
- Node.js
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.- PHP
- Laravel
- Node.js
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 realavailability() SDK call. Replace the markup, styling, product display, and /payments/checkout-session URL with your own application design.
- PHP
- Laravel
- Node.js
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.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 persistcompletionContext 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.
- PHP
- Laravel
- Node.js
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 savedcompletionContext. 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.
- PHP
- Laravel
- Node.js
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
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
completionContextonly with the pending merchant order; never return or log it. - Return only
gateway,mode, expiry, request ID, andcheckoutdata to the browser. - Treat Elements and provider browser events as UI signals, not payment proof.
- Use
completePayment()and fulfil only a verifiedPaymentStatus::Succeededresult. - 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.
