Skip to main content
Use Epay compatibility when you already have an Epay-style integration and need to keep the same request shape while moving payment traffic to Kyren Pay. New integrations should prefer native Kyren Checkout through the Quickstart, because native Checkout uses Kyren API authentication and the current order model directly. Epay source orders created through these compatibility endpoints flow into the same Kyren order and settlement system as native Checkout orders. The compatibility layer is only the entry point and response format.

​
Endpoint map

Existing Epay pathMethodPurposeKyren behavior
/epay/submit.phpGET or POSTPage redirect checkoutCreates or reuses an order, then returns HTTP 302 to /epay/redirect/{orderId} or an upstream payment page.
/epay/mapi.phpPOSTServer-to-server direct payment creationCreates or reuses an order and returns Epay-style fields such as payurl, qrcode, img, and trade_no depending on channel.
/epay/api.php?act=orderGET or POSTOrder queryQueries by out_trade_no or trade_no.
/epay/api.php?act=refundGET or POSTRefund compatibility pathCurrently returns an unsupported compatibility error. Refunds are handled separately with platform assistance.

​
Migration flow

  1. Replace your Epay base URL with the Kyren Pay API base URL while keeping the compatible path.
  2. Use your Kyren-issued pid and merchant key for Epay-compatible signing.
  3. Keep pid + sign authentication for Epay-compatible requests. Do not send x-api-key.
  4. Map your payment type values to supported values: alipay, wxpay, creditcard, crypto, or paynow.
  5. Route browser checkout traffic to submit.php or server-side payment creation to mapi.php.
  6. Verify payment results from the notify_url GET notification and return the plain string success after processing.
  7. Use api.php?act=order for compatibility order queries and reconcile the resulting Kyren orders and settlements.