SDKs
Official Elebne Pay SDKs — server SDKs (PHP, Java) that mint client secrets and verify webhooks, and client checkout SDKs (React, React Native, Flutter).
SDKs
Elebne Pay ships two kinds of official SDK, and a typical integration uses one of each:
- Server SDKs (PHP, Java) run on your backend. They hold your secret key (
sk_), mint theclientSecretyour checkout consumes, and verify webhook signatures. Thinkstripe-php/stripe-java. - Client SDKs (React, React Native, Flutter) run in your app. They render the hosted Elebne checkout, re-verify the result server-side, and never see a secret key.
PHP (server)
Mint client secrets and verify webhooks from PHP 8.1+
Java (server)
Mint client secrets and verify webhooks from Java 17
React (client)
Hosted checkout for React web apps
React Native (client)
Hosted checkout in a WebView for React Native
Flutter (client)
Hosted checkout in a WebView for Flutter
At a glance
| SDK | Package | Role | Install |
|---|---|---|---|
| PHP | elebne/pay-php | Server | composer require elebne/pay-php |
| Java | ai.elebne:pay-java | Server | ai.elebne:pay-java:0.1.0 |
| React | @elebne/pay-react | Client | npm install @elebne/pay-react |
| React Native | @elebne/pay-react-native | Client | npm install @elebne/pay-react-native react-native-webview |
| Flutter | elebne_pay_flutter | Client | pubspec.yaml (path / git ref) |
The server-and-client model
The two SDKs meet at the clientSecret:
Server mints the intent
Your backend calls POST /dev/intents with its sk_ key (via the PHP or Java SDK) and gets back a clientSecret.
Client renders the checkout
Your app hands that clientSecret to the React / React Native / Flutter SDK, which loads the hosted Elebne checkout surface.
Server confirms the outcome
The client SDK re-verifies the terminal status against the backend, and your server receives a signed payment.confirmed webhook. Fulfil the order only after verification.
Shared concepts
The three client checkout flows
Every client SDK (React, React Native, Flutter) exposes the same three flows:
- Flow A — server-minted (recommended). Your server mints the intent with its
sk_key and passes theclientSecretto the client viafetchClientSecret. The client never handles a key. Use this whenever you have a backend. - Flow B — no backend. Define a price in the Elebne dashboard, then pass a
publishableKey(pk_) pluspriceIdandquantity. The client SDK mints the intent itself. Use this for static sites with no server. - Flow C — verify callback (legacy). Pass a
publishableKey, amerchantOrderId, andflow: 'verify'. The SDK verifies an out-of-band payment against your order reference.
Amounts are in centimes
All amounts are integers in centimes — 50000 means 500.00 MRU. Never send a decimal.
Sandbox vs live is a property of the key
There is no separate sandbox hostname. A test key (sk_test_ / pk_test_) produces sandbox intents with no real money; a live key (sk_live_ / pk_live_) produces real payments. The client SDKs surface this as session.sandbox.
Webhook signatures
Server SDKs verify webhooks with the standard Elebne scheme — header X-Elebne-Signature: sha256=<hex>, signed content "{timestamp}.{rawBody}", HMAC-SHA256. See Webhooks for the full contract.
Next steps
- PHP SDK — mint client secrets and verify webhooks from your server
- React SDK — render the hosted checkout in a web app
- Pay API — the REST API the SDKs wrap
- Webhooks — signature verification and retries
- Integrations — drop-in plugins like WooCommerce
Was this page helpful?
Webhooks & Events
Receive real-time notifications for payment lifecycle events. Learn the 6 payment webhook events, their payloads, and how to verify signatures.
PHP SDK
Server-side PHP SDK for Elebne Pay — mint client secrets, retrieve/cancel/refund intents, and verify webhooks. PHP 8.1+, dependency-free.