Crypto-first Payment API: create a session and redirect to checkout_url.
Direct crypto is the recommended EcomTrade24 payment rail. Customers who already own crypto can pay from a wallet or exchange; no fiat purchase is started. If a customer needs to buy crypto first, optional card and local fiat-to-crypto routes can be offered through independent providers and verification may be required. Your backend sends the order details, receives a checkout URL, redirects the customer, and waits for the signed webhook.
Amount, currency, domain, customer email and order ID.
Use the returned checkout_url. Do not build your own provider URL.
Mark the order paid only after a final paid webhook/status.
Direct crypto first. Fiat-to-crypto only as fallback.
If you build your own payment-method selector, place crypto first. It sends customers who already own crypto directly to the dedicated crypto checkout. Card, PayPal-style and local methods are optional routes for customers who need to purchase crypto first through an independent provider.
method=cryptoExisting wallet or exchange → choose coin and exact network → send crypto → automatic order confirmation.
Card or local method → third-party fiat-to-crypto provider → provider availability and identity verification may apply.
{
"method": "crypto"
}
If you do not send a method, redirect to the returned Hosted Checkout and let EcomTrade24 present the crypto-first selector. Never replace checkout_url with a provider URL.
Never send a provider from the merchant shop.
Smart Routing means EcomTrade24 Pay chooses the best provider and fallback internally. Your shop must not send provider slugs like guardarian, cryptocom, epv2, malum, moonpay, stripe, rampnetwork, upi, interac, banxa or any other provider name.
Send amount, currency, domain, email, order_id, return_url and cancel_url. Then redirect to checkout_url.
Do not send provider, payment_provider, checkout_provider, m_provider_name, provider_mode, fallback_provider or a hardcoded provider link.
Important: If a response URL contains a provider parameter, that is internal handoff context generated by EcomTrade24 Pay. Use the URL exactly as returned. Do not create or edit it yourself.
Same session endpoint, different checkout mode by merchant plan.
Developers should not choose the checkout mode in the request. EcomTrade24 Pay detects the merchant package behind the API key and returns the correct checkout_url.
| Merchant plan | What happens after session creation | Developer rule |
|---|---|---|
| Free | Customer goes to EcomTrade24 Hosted Checkout. The hosted page shows available buyer-facing payment choices. | Create the session and redirect to checkout_url. Do not try to build Smart Routing. |
| Pro | Smart Routing can select the best available route and fallback based on settings, country, amount and method. | Create the session and redirect to checkout_url. Do not send a provider. |
| Unlimited | Smart Routing can use the full routing setup and high-volume rules configured for the merchant. | Same integration as Pro: no provider, no hardcoded route, use returned URL. |
The API key decides the plan. The plan decides whether the returned checkout is Hosted Checkout or Smart Routing.
The shop should not send smart_route=true, hosted=false, provider=... or any field that tries to force a route.
What the current API supports
Free merchants create sessions through the same API, but the customer is sent to the EcomTrade24 hosted checkout. Free integrations must not expect direct Smart Routing.
Pro/Unlimited merchants can use automated route selection, fallbacks and provider/currency rules for card, PayPal, Revolut, iDEAL, Klarna, crypto, UPI/IMPS, Interac and fallback methods. The shop still sends no provider.
Merchants can create hosted payment links from the dashboard. The link creates/uses gateway sessions behind the scenes.
Merchants can create simple hosted product/landing pages with checkout powered by EcomTrade24 Pay.
Your shop receives signed payment updates and should use those as the paid-state source of truth.
Your backend can check a session by session_id, order_id or number as a fallback.
Use /gateway/me.php to check package, checkout mode and available buyer-facing methods, including crypto, UPI and Interac when enabled/configured.
Reseller/white-label partners can manage their merchants through dedicated reseller endpoints.
Where enabled, one deterministic session address is monitored on Polygon and Ethereum. Supported POL, ETH, USDC or USDT is split by immutable contract rules into the platform fee wallet and the merchant vault.
Clear production integration flow
- 1. Customer clicks Pay once
Create or load the unpaid shop order first. Use one stable order ID for that order.
- 2. Your backend calls /gateway/session.php
Use JSON. Keep the API key on the server. Never call the Session API directly from frontend JavaScript.
- 3. API returns checkout_url
Save
session_id. Treatcheckout_urlas an opaque URL and use it exactly as returned. - 4. Redirect the customer browser immediately
Send the customer's browser to
checkout_url. Do not fetch that URL from your backend and do not create another session before redirecting. - 5. Retry safely with the same order_id
If your request is retried or the buyer clicks Pay again, reuse the same
order_id. EcomTrade24 can return the existing open session withreused: true. - 6. Customer pays
Direct crypto customers pay from their existing wallet or exchange. If the customer chooses an optional fiat-to-crypto route, the independent provider handles its own eligibility and verification steps.
- 7. Your webhook receives final status
Only then mark the order paid. Return pages are not proof of payment.
Authentication
Use your merchant API key from the merchant dashboard. The safest header is Authorization: Bearer YOUR_API_KEY. X-API-Key also works.
Authorization: Bearer YOUR_API_KEY
X-API-Key: YOUR_API_KEY
Check merchant capabilities
GET /gateway/me.phpUse this endpoint to confirm the API key, detect the merchant plan and read the recommended payment-method order. New clients should use recommended_method, method_order and each method's group. Direct crypto is recommended when available; Smart Routing remains an optional fiat-to-crypto fallback for eligible Pro/Unlimited merchants. The shop never sends a provider.
curl 'https://pay.ecomtrade24.com/gateway/me.php' \
-H 'Authorization: Bearer YOUR_API_KEY'
{
"ok": true,
"merchant_id": 12,
"email": "[email protected]",
"package": "pro",
"checkout_mode": "smart_router",
"recommended_method": "crypto",
"method_order": ["crypto","card","paypal","revolut","ideal","klarna","bank","upi","interac","other"],
"country": "DE",
"smart_router": {
"enabled_global": true,
"allowed_for_package": true,
"effective": true,
"methods": {
"card": {"enabled": true, "configured": true, "available": true},
"klarna": {"enabled": true, "configured": true, "available": false},
"paypal": {"enabled": true, "configured": true, "available": true},
"revolut":{"enabled": true, "configured": true, "available": true},
"bank": {"enabled": true, "configured": true, "available": true, "supported_bank_fiat": ["EUR", "USD"]},
"ideal": {"enabled": true, "configured": true, "available": false, "min_amount": 46.0, "currency": "EUR"},
"upi": {"enabled": true, "configured": true, "available": false, "min_amount": 1600.0, "currency": "INR", "country": "IN"},
"interac":{"enabled": true, "configured": true, "available": false, "min_amount": 100.0, "currency": "CAD", "country": "CA"},
"crypto": {"enabled": true, "configured": true, "available": true},
"other": {"enabled": true, "configured": true, "available": true}
}
}
}
You can skip method buttons and just create a session. Redirect to the returned checkout URL and let EcomTrade24 show the crypto-first selector. Eligible Pro/Unlimited accounts can still expose optional Smart Routing fiat-to-crypto fallbacks.
Show only buyer-facing methods that are available for the merchant. Still do not show provider names and do not let the shop force Smart Routing for Free merchants.
Create checkout session
POST /gateway/session.phpThis is the main endpoint for every merchant plan. Your backend sends order data and receives checkout_url. The API key decides whether this session becomes Hosted Checkout for a Free merchant or Smart Routing for a Pro/Unlimited merchant.
| Field | Required | Example | Explanation |
|---|---|---|---|
| amount | Yes | 49.99 | Order total. Dot decimal. Must be greater than 0. |
| currency | Yes | EUR | Fiat order currency like EUR, USD, GBP, CAD or INR. |
| domain | Yes | shop.example.com | Must be added/allowed in merchant shops. |
| Strongly recommended | [email protected] | Real customer email. Some routes require it. No proxy/fake email. | |
| customer_email | Optional alias | [email protected] | Alternative email field. |
| billing_email | Optional alias | [email protected] | Alternative billing email field. |
| order_id | Strongly recommended | ORD-10001 | Stable ID of your shop order. Reuse the same value for retries or repeated Pay clicks. This enables safe open-session reuse. Also accepted: merchant_ref. |
| return_url | Recommended | https://shop.example.com/success | Customer return page. Not proof of payment. |
| cancel_url | Recommended | https://shop.example.com/checkout | Customer cancel/back page. |
| country | Strongly recommended | DE | Two-letter buyer/billing country. Important for country-aware Smart Routing and local-method eligibility. |
| billing_country | Optional alias | DE | Alternative country field. |
| meta | Optional | {"source":"woocommerce"} | Small metadata object. Do not include sensitive data. |
| method | Optional advanced | crypto | Buyer-facing method only. Never a provider. Recommended default: crypto. Other values are optional fiat-to-crypto fallbacks: card, paypal, revolut, ideal, klarna, bank, upi, interac, other. |
| bank_fiat_currency | Optional advanced | EUR | Only for bank/open-banking style methods when needed. |
After a successful Session API response, immediately send the customer's browser to checkout_url. Do not request checkout_url from your server, do not inspect or rebuild it, and do not create a second payment session before the redirect.
Use one stable order_id for one shop order. If the API call is retried with the same open order, EcomTrade24 may return the existing session and include "reused": true. Never generate a fresh order ID just because the customer clicked Pay again.
curl -X POST 'https://pay.ecomtrade24.com/gateway/session.php' \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"amount": "49.99",
"currency": "EUR",
"domain": "shop.example.com",
"order_id": "ORD-10001",
"email": "[email protected]",
"country": "DE",
"return_url": "https://shop.example.com/order/success",
"cancel_url": "https://shop.example.com/checkout",
"meta": {
"source": "woocommerce"
}
}'
curl -X POST 'https://pay.ecomtrade24.com/gateway/session.php' \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"amount": "149.00",
"currency": "EUR",
"domain": "shop.example.com",
"order_id": "ORD-10002",
"email": "[email protected]",
"country": "DE",
"method": "crypto",
"return_url": "https://shop.example.com/order/success",
"cancel_url": "https://shop.example.com/checkout"
}'
Recommended method: crypto. Optional fallback values: card, paypal, revolut, ideal, klarna, bank, upi, interac, other. Follow method_order from /gateway/me.php and show only methods reported available. Local methods are country/currency gated: UPI/IMPS requires India/INR, Interac requires Canada/CAD.
{
"ok": true,
"session_id": 1459,
"checkout_url": "https://pay.ecomtrade24.com/hosted-checkout.php?session=1459",
"direct_url": null,
"warmup_url": null,
"selected_provider": null,
"smart_route": false,
"expires_at": "2026-04-29 12:30:00"
}
The exact path inside checkout_url can differ by plan, method and routing state. Treat it as opaque. The only customer navigation target your integration needs is checkout_url.
{
"ok": true,
"session_id": 1459,
"checkout_url": "https://pay.ecomtrade24.com/hosted-checkout.php?session=1459",
"direct_url": null,
"warmup_url": null,
"selected_provider": null,
"smart_route": false,
"expires_at": "2026-04-29 12:30:00",
"reused": true
}
reused: true means the request matched an existing open session for the same order context. Redirect the browser to the returned checkout_url exactly the same way; do not create another order ID.
$data = json_decode($response, true);
if (empty($data['ok']) || empty($data['checkout_url'])) {
// Handle the API error. Do not create a new order ID.
exit;
}
// Send the CUSTOMER browser to the URL returned by EcomTrade24.
header('Location: ' . $data['checkout_url'], true, 303);
exit;
const response = await fetch('/your-server/create-payment', {
method: 'POST'
});
const payment = await response.json();
if (payment.checkout_url) {
window.location.assign(payment.checkout_url);
}
Your frontend may receive checkout_url from your own backend. Never expose the EcomTrade24 API key to browser JavaScript.
Smart Routing explained clearly
Smart Routing is not: your shop choosing Guardarian, Crypto.com, Malum, PayPal, Stripe or any other provider.
Smart Routing is: the optional fiat-to-crypto fallback layer for Pro/Unlimited merchants. Direct crypto remains the recommended payment rail. For customers who need fiat, EcomTrade24 can choose an eligible provider based on country, amount, currency, method availability, fallback rules and provider status.
Free merchant behavior: the same session call returns Hosted Checkout, not Smart Routing. That is expected and should not be bypassed.
The merchant sees: one API endpoint and one checkout URL. The customer sees a checkout/payment flow. The provider details stay internal.
| Buyer-facing method key | Customer option | Routing note |
|---|---|---|
| crypto | Direct crypto checkout | Recommended. Customer pays from an existing wallet or exchange; no fiat purchase is started. |
| card | Card fiat-to-crypto | Optional fallback. Smart Routing chooses an eligible third-party crypto-purchase route; verification may be required. |
| paypal | PayPal route | Country-aware route: Banxa for eligible Europe/EUR buyers, Topper for eligible USA/USD buyers, with configured fallbacks. |
| revolut | Revolut route | Usually EUR-gated depending on provider configuration. |
| ideal | iDEAL | Country/amount gated, normally NL/BE and EUR. |
| klarna | Klarna | Country/amount gated and normally EUR. |
| upi | UPI / IMPS | Local India route. Requires INR, India customer context and local minimum amount. |
| interac | Interac | Local Canada route. Requires CAD, Canada customer context and local minimum amount. |
| other | More payment options | Fallback/more-options route. Provider choice stays internal. |
| Question | Answer |
|---|---|
| Do Free merchants get Smart Routing? | No. Free merchants use Hosted Checkout. |
| Do Pro/Unlimited merchants get Smart Routing? | Yes, when Smart Routing is enabled for their account/package. |
Do I send provider? | No. Never from the shop integration. |
Do I send method? | Only if you build buyer-facing method buttons. Otherwise omit it. |
| Which URL do I redirect to? | Always the returned checkout_url, exactly as returned, in the customer browser. |
| Can I edit the returned URL? | No. Use it exactly as returned. |
| Where do payouts go? | V3 merchant amounts are sent to the chain-specific merchant vault and can be released only to the fixed Polygon or Ethereum merchant wallet configured for that vault. |
| Who handles KYC if needed? | The underlying payment/on-ramp provider, not your shop API call. |
Check session status
GET /gateway/session_status.phpUse this as a fallback, not as your main payment confirmation. Look up by session_id, order_id, or number=session_1459.
curl 'https://pay.ecomtrade24.com/gateway/session_status.php?session_id=1459' \
-H 'Authorization: Bearer YOUR_API_KEY'
{
"ok": true,
"session": {
"id": 1459,
"order_id": "ORD-10001",
"status": "settled",
"amount": "49.99",
"currency": "EUR",
"shop_domain": "shop.example.com",
"payment_url": "https://pay.ecomtrade24.com/checkout.php?session=1459",
"txid": "0x...",
"txid_in": "0x...",
"txid_out": "0x...",
"last_error": null
}
}
paid, settled, completed, expired or failed. Too much polling can trigger rate_limited or temporarily_blocked.Webhooks: your real paid confirmation
Configure webhook URL and secret in the merchant dashboard. EcomTrade24 Pay sends a signed POST request. Your system must verify the signature and process the event idempotently.
{
"event": "payment.completed",
"session_id": 1459,
"order_id": "ORD-10001",
"status": "paid",
"amount": "49.99",
"currency": "EUR",
"merchant_id": 12,
"txid": "0x..."
}<?php
$raw = file_get_contents('php://input');
$received = $_SERVER['HTTP_X_ECOMTRADE24_SIGNATURE']
?? $_SERVER['HTTP_X_SIGNATURE']
?? '';
$secret = 'YOUR_WEBHOOK_SECRET';
$expected = hash_hmac('sha256', $raw, $secret);
if (!hash_equals($expected, $received)) {
http_response_code(401);
exit('invalid signature');
}
$payload = json_decode($raw, true);
// 1. Check session_id/order_id
// 2. Process only once
// 3. Mark paid only for final paid statuses
http_response_code(200);
echo 'ok';
paid, settled or completed as final paid, depending on your received payload. Do not mark paid for created, awaiting_payment, pending, expired, failed or manual_review.Payment links & hosted products
These are merchant dashboard features built on top of the same session engine. They are useful when a merchant does not want to integrate a shop plugin or custom API immediately.
Create a link with amount, currency, title, customer email, expiry and optional continue URL. The customer opens the link and pays through EcomTrade24 Pay.
Open Payment LinksCreate simple product pages with price, currency, description, images and checkout. Good for quick sales pages without WooCommerce.
Open ProductsReseller / white-label API overview
Reseller endpoints are for approved reseller partners who run their own branded merchant platform. Normal merchants do not need these endpoints.
| Endpoint | Purpose |
|---|---|
| GET /api/reseller_profile.php | Read reseller profile/status. |
| GET/POST /api/reseller_merchants.php | List or create/sync reseller merchants. |
| GET/POST /api/reseller_merchant.php | Read or update one reseller merchant. |
| GET /api/reseller_merchant_access.php | Check merchant access/approval state. |
| POST /api/reseller_merchant_reveal_key.php | Reveal/provision a merchant API key where allowed. |
| GET/POST /api/reseller_webhook.php | Manage reseller webhook configuration. |
| POST /api/reseller_merchant_webhook.php | Manage merchant webhook settings for reseller-managed merchants. |
Common errors and how to fix them
| Error | Meaning | Fix |
|---|---|---|
| missing_api_key | No API key sent. | Send Authorization: Bearer YOUR_API_KEY. |
| invalid_api_key | API key not found. | Copy the current key from the merchant dashboard. |
| merchant_disabled | Merchant account is not active. | Contact support or activate the merchant. |
| invalid_json | Request body is not valid JSON. | Send valid JSON and Content-Type: application/json. |
| invalid_domain | Missing or invalid domain. | Send domain like shop.example.com. |
| domain_not_allowed | Domain is not approved for the merchant. | Add the shop domain in merchant settings / go-live checklist. |
| invalid_amount | Amount is missing or <= 0. | Send a positive numeric amount. |
| invalid_currency | Currency missing or invalid. | Send fiat code like EUR or USD. |
| missing_merchant_payout_wallet | Merchant has no payout wallet. | Add USDC Polygon payout wallet before accepting payments. |
| invalid_merchant_payout_wallet | Payout wallet format is invalid. | Use a valid EVM/Polygon wallet address. |
| valid_customer_email_required | Selected route requires a real customer email. | Send the real buyer email. Do not use proxy/fake emails. |
| rate_limited | Too many API/status requests. | Reduce polling and obey Retry-After. |
| temporarily_blocked | Status endpoint was abused. | Stop polling and wait until retry_after. |
Go-live checklist
- ✅ Merchant account is active.
- ✅ Shop domain is added and allowed.
- ✅ USDC Polygon payout wallet is saved.
- ✅ Webhook URL and webhook secret are configured.
- ✅ API key is used only on the backend.
- ✅ Session request sends no provider.
- ✅ Customer is redirected to returned
checkout_url. - ✅ Order is marked paid only after webhook/final status.
- ✅ Polling stops after final status.
- ✅ Real customer emails are sent for payment sessions.