Merchant API • Direct Crypto • Hosted Checkout • Optional Fiat-to-Crypto • Webhooks

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.

1. Send order

Amount, currency, domain, customer email and order ID.

2. Redirect buyer

Use the returned checkout_url. Do not build your own provider URL.

3. Confirm by webhook

Mark the order paid only after a final paid webhook/status.

Recommended integration model

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.

1 · Recommended: method=crypto

Existing wallet or exchange → choose coin and exact network → send crypto → automatic order confirmation.

2 · Optional fallback

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.

Read this first

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.

Correct

Send amount, currency, domain, email, order_id, return_url and cancel_url. Then redirect to checkout_url.

Wrong

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.

Plan-based checkout behavior

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 planWhat happens after session creationDeveloper rule
FreeCustomer 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.
ProSmart 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.
UnlimitedSmart 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.
Correct mental model

The API key decides the plan. The plan decides whether the returned checkout is Hosted Checkout or Smart Routing.

Wrong mental model

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

Hosted Checkout

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.

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.

Payment Links

Merchants can create hosted payment links from the dashboard. The link creates/uses gateway sessions behind the scenes.

Product Pages

Merchants can create simple hosted product/landing pages with checkout powered by EcomTrade24 Pay.

Signed Webhooks

Your shop receives signed payment updates and should use those as the paid-state source of truth.

Session Status API

Your backend can check a session by session_id, order_id or number as a fallback.

Merchant Capability API

Use /gateway/me.php to check package, checkout mode and available buyer-facing methods, including crypto, UPI and Interac when enabled/configured.

Reseller API

Reseller/white-label partners can manage their merchants through dedicated reseller endpoints.

Non-Custodial Settlement V3

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. 1. Customer clicks Pay once

    Create or load the unpaid shop order first. Use one stable order ID for that order.

  2. 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. 3. API returns checkout_url

    Save session_id. Treat checkout_url as an opaque URL and use it exactly as returned.

  4. 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. 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 with reused: true.

  6. 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. 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
Do not expose the API key. Never put it in JavaScript, HTML, mobile apps or public GitHub repositories. Use it only on your server.

Check merchant capabilities

GET /gateway/me.php

Use 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}
    }
  }
}
For simple integration

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.

For advanced method buttons

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.php

This 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.

Important for developers: do not add a parameter to force Smart Routing. Free merchants are intentionally routed through Hosted Checkout. Pro/Unlimited merchants receive Smart Routing only when it is enabled for their package and account.
FieldRequiredExampleExplanation
amountYes49.99Order total. Dot decimal. Must be greater than 0.
currencyYesEURFiat order currency like EUR, USD, GBP, CAD or INR.
domainYesshop.example.comMust be added/allowed in merchant shops.
emailStrongly recommended[email protected]Real customer email. Some routes require it. No proxy/fake email.
customer_emailOptional alias[email protected]Alternative email field.
billing_emailOptional alias[email protected]Alternative billing email field.
order_idStrongly recommendedORD-10001Stable 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_urlRecommendedhttps://shop.example.com/successCustomer return page. Not proof of payment.
cancel_urlRecommendedhttps://shop.example.com/checkoutCustomer cancel/back page.
countryStrongly recommendedDETwo-letter buyer/billing country. Important for country-aware Smart Routing and local-method eligibility.
billing_countryOptional aliasDEAlternative country field.
metaOptional{"source":"woocommerce"}Small metadata object. Do not include sensitive data.
methodOptional advancedcryptoBuyer-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_currencyOptional advancedEUROnly for bank/open-banking style methods when needed.
Production rule: create once, then redirect

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.

Recommended request: no provider, no hardcoded route
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"
    }
  }'
Advanced request: customer selected a payment method, not a provider
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.

Typical success response
{
  "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.

Retry / reused open session
{
  "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.

Server-side PHP redirect
$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;
Frontend redirect after your backend created the session
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 keyCustomer optionRouting note
cryptoDirect crypto checkoutRecommended. Customer pays from an existing wallet or exchange; no fiat purchase is started.
cardCard fiat-to-cryptoOptional fallback. Smart Routing chooses an eligible third-party crypto-purchase route; verification may be required.
paypalPayPal routeCountry-aware route: Banxa for eligible Europe/EUR buyers, Topper for eligible USA/USD buyers, with configured fallbacks.
revolutRevolut routeUsually EUR-gated depending on provider configuration.
idealiDEALCountry/amount gated, normally NL/BE and EUR.
klarnaKlarnaCountry/amount gated and normally EUR.
upiUPI / IMPSLocal India route. Requires INR, India customer context and local minimum amount.
interacInteracLocal Canada route. Requires CAD, Canada customer context and local minimum amount.
otherMore payment optionsFallback/more-options route. Provider choice stays internal.
QuestionAnswer
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.php

Use 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
  }
}
Polling limit: do not poll every second. Use 10–20 seconds while the checkout is open, stop after final statuses like 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.

Example payload
{
  "event": "payment.completed",
  "session_id": 1459,
  "order_id": "ORD-10001",
  "status": "paid",
  "amount": "49.99",
  "currency": "EUR",
  "merchant_id": 12,
  "txid": "0x..."
}
PHP signature verification
<?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 statuses: treat 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.

Reseller / 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.

EndpointPurpose
GET /api/reseller_profile.phpRead reseller profile/status.
GET/POST /api/reseller_merchants.phpList or create/sync reseller merchants.
GET/POST /api/reseller_merchant.phpRead or update one reseller merchant.
GET /api/reseller_merchant_access.phpCheck merchant access/approval state.
POST /api/reseller_merchant_reveal_key.phpReveal/provision a merchant API key where allowed.
GET/POST /api/reseller_webhook.phpManage reseller webhook configuration.
POST /api/reseller_merchant_webhook.phpManage merchant webhook settings for reseller-managed merchants.
Open full reseller docs

Common errors and how to fix them

ErrorMeaningFix
missing_api_keyNo API key sent.Send Authorization: Bearer YOUR_API_KEY.
invalid_api_keyAPI key not found.Copy the current key from the merchant dashboard.
merchant_disabledMerchant account is not active.Contact support or activate the merchant.
invalid_jsonRequest body is not valid JSON.Send valid JSON and Content-Type: application/json.
invalid_domainMissing or invalid domain.Send domain like shop.example.com.
domain_not_allowedDomain is not approved for the merchant.Add the shop domain in merchant settings / go-live checklist.
invalid_amountAmount is missing or <= 0.Send a positive numeric amount.
invalid_currencyCurrency missing or invalid.Send fiat code like EUR or USD.
missing_merchant_payout_walletMerchant has no payout wallet.Add USDC Polygon payout wallet before accepting payments.
invalid_merchant_payout_walletPayout wallet format is invalid.Use a valid EVM/Polygon wallet address.
valid_customer_email_requiredSelected route requires a real customer email.Send the real buyer email. Do not use proxy/fake emails.
rate_limitedToo many API/status requests.Reduce polling and obey Retry-After.
temporarily_blockedStatus 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.