The simple rule: create a session and redirect to checkout_url.
Your shop does not need to know which payment provider is used. EcomTrade24 Pay decides the correct checkout mode for the merchant plan. Free merchants receive Hosted Checkout. Pro and Unlimited merchants can receive Smart Routing. 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.
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. 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.
Reseller/white-label partners can manage their merchants through dedicated reseller endpoints.
Merchant settlements are designed around USDC on Polygon payout wallets.
Clear production integration flow
- 1. Customer clicks Pay
Your shop has an unpaid order with amount and currency.
- 2. Your backend calls /gateway/session.php
Use JSON. Keep the API key on the server. Do not call this from frontend JavaScript.
- 3. API returns checkout_url
Save the session_id on your order if possible.
- 4. Redirect customer to checkout_url
Do not change the URL. Do not append provider names.
- 5. Customer pays
Provider-side KYC/card checks, if triggered, are handled by the underlying payment/on-ramp provider.
- 6. 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 is valid and to detect the merchant plan before building optional method buttons. Free merchants use Hosted Checkout. Pro/Unlimited merchants can use Smart Routing when enabled. The shop still 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",
"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},
"other": {"enabled": true, "configured": true, "available": true}
}
}
}
You can skip method buttons and just create a session. EcomTrade24 will return the correct checkout URL for the merchant plan: Hosted Checkout for Free, Smart Routing for Pro/Unlimited when active.
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 | Recommended | ORD-10001 | Your own order number. 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 | Optional | DE | Two-letter buyer country. Helps country-aware routing. |
| billing_country | Optional alias | DE | Alternative country field. |
| meta | Optional | {"source":"woocommerce"} | Small metadata object. Do not include sensitive data. |
| method | Optional advanced | card | Buyer-facing method only. Never a provider. Use only if you show method buttons. |
| bank_fiat_currency | Optional advanced | EUR | Only for bank/open-banking style methods when needed. |
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": "card",
"return_url": "https://shop.example.com/order/success",
"cancel_url": "https://shop.example.com/checkout"
}'
Allowed method values: card, klarna, paypal, revolut, bank, ideal, other. Show only methods that /gateway/me.php says are available.
{
"ok": true,
"session_id": 1459,
"checkout_url": "https://pay.ecomtrade24.com/hosted-checkout.php?session=1459",
"checkout_mode": "hosted",
"smart_route": false,
"expires_at": "2026-04-29 12:30:00"
}
Free merchants use Hosted Checkout. Redirect the customer to checkout_url. Do not try to add provider or Smart Routing fields.
{
"ok": true,
"session_id": 1460,
"checkout_url": "https://pay.ecomtrade24.com/checkout-continue.php?session=1460",
"checkout_mode": "smart_router",
"direct_url": null,
"warmup_url": "https://pay.ecomtrade24.com/checkout-continue.php?session=1460",
"selected_provider": null,
"smart_route": true,
"expires_at": "2026-04-29 12:30:00"
}
Pro/Unlimited merchants can use Smart Routing. Still use only checkout_url. selected_provider is internal and can be null or changed by fallback logic.
Smart Routing explained clearly
Smart Routing is not: your shop choosing Guardarian, Crypto.com, Malum, PayPal, Stripe or any other provider.
Smart Routing is: available for Pro/Unlimited merchants when enabled. Your shop sends the order, and EcomTrade24 Pay decides the best available route based on package, 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.
| 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. |
| Can I edit the returned URL? | No. Use it exactly as returned. |
| Where do payouts go? | Merchant payout is designed for the configured USDC Polygon wallet. |
| 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.