Migración con IA

Binance Pay migration

Use an AI agent to replace Binance Pay orders, checkout URLs, webhooks, request signing, refunds, and status handling with MakePay APIs and SDKs.

Overview

This AI compatibility guide gives a senior developer or coding agent a direct path for replacing Binance Pay order creation, checkout URLs, QR/deeplink checkout artifacts, order notification webhooks, order polling, close/refund flows, and status reconciliation with MakePay. It covers the Binance Pay v2 order API, merchantTradeNo, prepayId, checkoutUrl, BinancePay-* request headers, HMAC-SHA512 request signing, RSA webhook verification, PAY_SUCCESS, PAY_CLOSED, order query statuses, and SDK installation.

Use it when the existing codebase calls Binance Pay Merchant Acquiring (C2B), stores Binance prepayId or merchantTradeNo values on orders, redirects buyers to checkoutUrl, renders Binance QR/deeplink/universal URL data, verifies Binance Pay notification signatures, or polls Binance Pay order/refund state before fulfillment. Binance documents the current integration model in the API Specification Common Rules, Authentication guide, Create Order v2 API, Query Order v2 API, Order Notification webhook, Webhook Common Rules, Webhook certificate API, Close Order API, and Refund Order API.

Payment links API

Webhook verification

SDK libraries

Migration map

Binance Pay integrations usually create a v2 order with merchantTradeNo, store the returned prepayId, redirect buyers to checkoutUrl or render QR/deeplink artifacts, then reconcile PAY_SUCCESS, PAY_CLOSED, and query/refund statuses. In MakePay, use payment links, signed webhooks, and SDK helpers for the same order flow.

Binance Pay surface	MakePay replacement
`https://bpay.binanceapi.com` base URL	MakeCrypto company/API credential configuration
`BinancePay-Certificate-SN` API identity key and API secret	`X-MakeCrypto-Key-Id` and `X-MakeCrypto-Key-Secret` headers or SDK credentials
`BinancePay-Timestamp`, `BinancePay-Nonce`, and uppercase HMAC-SHA512 `BinancePay-Signature` requests	MakePay SDK authentication or MakeCrypto API credential headers
`POST /binancepay/openapi/v2/order`	`POST /api/partner/v1/makepay/payment-links` or SDK create-payment-link helper
`merchantTradeNo`	`merchantOrderId`; keep it unique per order
`prepayId`, webhook `bizId`, and `bizIdStr`	`paymentLink.uid`; keep a legacy alias during cutover
Response `checkoutUrl`	`paymentLink.publicUrl`
Response `qrcodeLink`, `qrContent`, `deeplink`, and `universalUrl`	Hosted MakePay checkout state; avoid storing provider artifacts as order URLs
`orderAmount` and `currency`	`payload.amount` and `payload.currency` or exact `payload.asset`
`fiatAmount` and `fiatCurrency`	`payload.amount` and fiat/display currency configuration
`supportPayCurrency`	MakePay exact `payload.asset` only when the business must force buyer assets
`goods.goodsName`, `goods.goodsDetail`, `referenceGoodsId`, `goodsType`, and `goodsCategory`	`label`, `description`, `merchantOrderId`, and internal metadata
`buyer.buyerEmail`, buyer name, phone, and `passThroughInfo`	`clientEmail`, customer metadata, and internal metadata
`returnUrl`, `cancelUrl`, and per-order `webhookUrl`	MakePay hosted-page redirect handling plus MakePay webhook endpoint
`orderExpireTime`	MakePay payment-link expiry and late-payment business rules
Order notification `bizType=PAY` with `bizStatus=PAY_SUCCESS`, `PAY_CLOSED`, or direct-debit `PAY_FAIL`	`makepay.payment.status_changed` and normalized order states
Notification `data` JSON string with `merchantTradeNo`, `totalFee`, `currency`, and `transactionId`	MakePay event payload plus `paymentLink.uid` idempotency
Webhook headers `BinancePay-Certificate-SN`, `BinancePay-Nonce`, `BinancePay-Timestamp`, `BinancePay-Signature`	MakePay `x-makepay-signature` HMAC verification over the raw request body
`POST /binancepay/openapi/certificates` public-key lookup for RSA webhook verification	MakePay webhook secret configured in MakeCrypto
`POST /binancepay/openapi/v2/order/query` statuses `INITIAL`, `PENDING`, `PAID`, `CANCELED`, `ERROR`, `REFUNDING`, `REFUNDED`, `FULL_REFUNDED`, `EXPIRED`	MakePay payment-link lookup and normalized paid, pending, failed, refunded, and expired states
`POST /binancepay/openapi/order/close` and webhook `PAY_CLOSED`	MakePay link expiry/cancellation or manual close workflow
`POST /binancepay/openapi/order/refund` with `refundStatus` `INITIAL`, `PENDING`, `CANCELLED`, `REFUNDED`	MakePay refund or manual support workflow

For a clean migration, keep provider-specific IDs separate. Existing Binance Pay orders should continue to reconcile until they are paid, closed, expired, cancelled, errored, refunded, fully refunded, or manually closed by current business rules, while new orders use MakePay.

SDK install commands

Pick the SDK that matches the service being migrated. These are the same quick commands shown on the MakePay SDK cards.

npm install @makecrypto/makepay
composer require makepay/makepay-php
go get github.com/makecryptoio/makepay-go
pip install makepay
cargo add makepay

implementation("io.makecrypto:makepay:0.3.0")

.package(url: "https://github.com/makecryptoio/makepay-swift-sdk.git", from: "0.3.0")

Use the SDK for payment-link creation and webhook verification whenever the language supports it. If a service has a custom HTTP client layer, call the payment-links API directly and keep the provider adapter small.

Agent prompts

Inventory Binance Pay usage

You are migrating this repository from Binance Pay to MakePay. Search for
Binance Pay API clients, bpay.binanceapi.com, binancepay/openapi,
/binancepay/openapi/v2/order, /binancepay/openapi/v2/order/query,
/binancepay/openapi/order/close, /binancepay/openapi/order/refund,
/binancepay/openapi/certificates, BinancePay-Certificate-SN,
BinancePay-Timestamp, BinancePay-Nonce, BinancePay-Signature, HMAC-SHA512,
RSA webhook verification, merchantTradeNo, prepayId, bizId, bizIdStr,
checkoutUrl, qrcodeLink, qrContent, deeplink, universalUrl, orderAmount,
currency, fiatAmount, fiatCurrency, supportPayCurrency, goodsName, goodsDetail,
referenceGoodsId, buyerEmail, passThroughInfo, returnUrl, cancelUrl,
webhookUrl, orderExpireTime, PAY_SUCCESS, PAY_CLOSED, PAY_FAIL, INITIAL,
PENDING, PAID, CANCELED, ERROR, REFUNDING, REFUNDED, FULL_REFUNDED, EXPIRED,
refundRequestId, refundStatus, and Binance Pay webhook response handling.

Return a file-by-file migration plan with the exact functions that create
Binance Pay orders, sign requests, store prepay IDs, redirect buyers, render QR
or deeplink checkout data, verify notifications, fetch order/refund status,
close orders, refund orders, and reconcile order status. Do not edit files yet.

Replace order creation

Implement MakePay payment-link creation in the existing Binance Pay order
creation path. Use the official MakePay SDK for this stack when available;
otherwise call POST /api/partner/v1/makepay/payment-links.

Remove BinancePay-Certificate-SN, BinancePay-Timestamp, BinancePay-Nonce, and
HMAC-SHA512 request-signing code from the new-order path. Map merchantTradeNo
to merchantOrderId, orderAmount to payload.amount, currency to payload.currency
or payload.asset, fiatAmount/fiatCurrency to the equivalent display or pricing
currency configuration, supportPayCurrency to an exact asset only when the
business must force buyer assets, goodsName to label, goodsDetail to
description, buyerEmail to clientEmail, and passThroughInfo/referenceGoodsId to
internal metadata.

Store paymentLink.uid and paymentLink.publicUrl, and keep nullable legacy
Binance Pay prepayId and merchantTradeNo fields for historical records.

Replace hosted checkout and QR artifacts

Replace Binance Pay checkoutUrl redirects with MakePay paymentLink.publicUrl.
Do not carry forward Binance qrcodeLink, qrContent, deeplink, universalUrl,
paymentInstructions, payerDetail, or Binance app-specific URL fields as the
primary order URL for new MakePay orders; those are provider-specific checkout
artifacts.

Find any frontend that renders Binance QR codes, deeplinks, universal links, or
Binance app buttons. For one-off order checkout, replace it with MakePay hosted
checkout, embedded checkout route, or modal script depending on the existing UX.
If the product still needs a dedicated app deep-link experience, keep it behind
a provider flag until all old Binance Pay orders are reconciled, then design a
MakePay-native flow separately.

Replace webhook verification

Replace Binance Pay order notification handling with MakePay webhook
verification. For legacy Binance Pay notifications, preserve RSA verification
until open Binance Pay orders are closed: read the exact raw request body,
build timestamp + LF + nonce + LF + body + LF from BinancePay-Timestamp and
BinancePay-Nonce, base64-decode BinancePay-Signature, select the Binance public
key matching BinancePay-Certificate-SN from /binancepay/openapi/certificates,
and verify SHA256withRSA before processing. Keep the required Binance response
shape only for legacy Binance Pay endpoints: {"returnCode":"SUCCESS","returnMessage":null}.

For new MakePay events, read the exact raw request body before JSON parsing,
parse x-makepay-signature, verify timestamp tolerance and HMAC digest with the
MakePay webhook secret, then process only trusted events.

Treat makepay.payment.status_changed as the primary order reconciliation event
and make updates idempotent by delivery ID and payment-link UID. For legacy
Binance Pay notifications, use bizIdStr or prepayId plus bizStatus and
transactionId for idempotency.

Normalize statuses

Map legacy Binance Pay statuses explicitly during cutover. PAY_SUCCESS and
query status PAID can complete the order only after amount, currency,
merchantTradeNo, prepayId, and provider checks pass. INITIAL and PENDING should
not grant goods. PAY_CLOSED, CANCELED, EXPIRED, and ERROR should close the
payment without marking the order paid. PAY_FAIL is mainly direct-debit
failure; route it to failed/manual-review logic if this integration used direct
debit. REFUNDING should keep the order in a refund-pending state. REFUNDED and
FULL_REFUNDED should update refund state without double-crediting or regressing
fulfillment.

Dual-run cutover

Add a migration flag so newly created orders use MakePay while existing Binance
Pay orders can still receive notifications and order/refund polling until they
are paid, closed, expired, cancelled, errored, refunding, refunded, fully
refunded, or manually closed through the current business rules. Route callbacks
by provider, keep provider-specific IDs separate, and add logs that include
provider, order ID, payment UID, delivery ID, legacy Binance Pay prepayId,
merchantTradeNo, bizIdStr, bizStatus, transactionId, refundRequestId,
refundStatus, amount, currency, and normalized status.

Remove Binance API identity keys, API secret keys, HMAC-SHA512 signing helpers,
RSA certificate caching, BinancePay-* webhook verification, checkoutUrl/QR/deep
link rendering, order polling, close-order code, and refund-order code only
after there are no open legacy Binance Pay orders or refunds.

Write tests

Add or update tests for MakePay payment-link creation, failed authentication,
webhook signature rejection, successful makepay.payment.status_changed handling,
duplicate webhook delivery idempotency, legacy Binance Pay notification routing
during cutover, Binance RSA signature rejection, certificate-serial mismatch,
checkoutUrl replacement, QR/deeplink/universalUrl artifact removal, INITIAL and
PENDING not granting goods, PAY_SUCCESS/PAID completion, PAY_CLOSED closure,
CANCELED/EXPIRED/ERROR closure, PAY_FAIL direct-debit handling, REFUNDING
pending refund state, REFUNDED/FULL_REFUNDED refund state, legacy query-order
polling fallback, legacy refund polling fallback, and buyer redirect URL
generation.

Use mocked MakePay SDK/API responses. Do not hit production APIs in tests.

Copy migration Markdown

The block below is a compact agent-ready brief for repository migrations. Copy it into Codex, Claude Code, Cursor, or another codebase-aware assistant when you want the model to perform the migration against a real project.

Agent-ready Binance Pay migration Markdown

# Migrate Binance Pay to MakePay

Use this as the working brief for an AI coding agent. Replace Binance Pay order creation, checkout URLs, QR/deeplink checkout artifacts, order notification webhooks, order polling, close/refund flows, status reconciliation, and provider API usage with MakePay payment links, signed webhooks, and the SDK that matches the codebase.

## Target MakePay SDK

Choose one install command for the stack being migrated:

```bash
npm install @makecrypto/makepay
composer require makepay/makepay-php
go get github.com/makecryptoio/makepay-go
pip install makepay
cargo add makepay
```

For JVM services use:

```kotlin
implementation("io.makecrypto:makepay:0.1.0")
```

For Swift Package Manager use:

```swift
.package(url: "https://github.com/makecryptoio/makepay-swift-sdk.git", from: "0.3.0")
```

## Migration map

- Binance Pay `https://bpay.binanceapi.com` base URL -> MakeCrypto company/API credential configuration.
- Binance Pay `BinancePay-Certificate-SN` API identity key and API secret -> MakePay `X-MakeCrypto-Key-Id` and `X-MakeCrypto-Key-Secret` headers or SDK credentials.
- Binance Pay request headers `BinancePay-Timestamp`, `BinancePay-Nonce`, and uppercase HMAC-SHA512 `BinancePay-Signature` -> MakePay SDK authentication or MakeCrypto API credential headers.
- Binance Pay `POST /binancepay/openapi/v2/order` -> MakePay `POST /api/partner/v1/makepay/payment-links` or the SDK create-payment-link helper.
- Binance Pay `merchantTradeNo` -> MakePay `merchantOrderId`; keep it unique per order.
- Binance Pay `prepayId`, webhook `bizId`, and webhook `bizIdStr` -> MakePay `paymentLink.uid`; keep the old IDs in a migration alias table while orders are in flight.
- Binance Pay response `checkoutUrl` -> MakePay `paymentLink.publicUrl`.
- Binance Pay response `qrcodeLink`, `qrContent`, `deeplink`, and `universalUrl` -> hosted MakePay checkout state; avoid storing provider artifacts as order URLs.
- Binance Pay `orderAmount` and `currency` -> MakePay `payload.amount` and `payload.currency` or exact `payload.asset`.
- Binance Pay `fiatAmount` and `fiatCurrency` -> MakePay amount plus fiat/display currency configuration.
- Binance Pay `supportPayCurrency` -> MakePay exact `payload.asset` only when the business must force buyer assets.
- Binance Pay `goods.goodsName`, `goods.goodsDetail`, `referenceGoodsId`, `goodsType`, and `goodsCategory` -> MakePay `label`, `description`, `merchantOrderId`, and internal metadata.
- Binance Pay `buyer.buyerEmail`, buyer name, phone, and `passThroughInfo` -> MakePay `clientEmail`, customer metadata, and internal metadata.
- Binance Pay `returnUrl`, `cancelUrl`, and per-order `webhookUrl` -> MakePay hosted-page redirect handling plus MakePay webhook endpoint.
- Binance Pay `orderExpireTime` -> MakePay payment-link expiry and late-payment business rules.
- Binance Pay order notification `bizType=PAY` with `bizStatus=PAY_SUCCESS`, `PAY_CLOSED`, or direct-debit `PAY_FAIL` -> MakePay `makepay.payment.status_changed` and normalized order states.
- Binance Pay notification `data` JSON string with `merchantTradeNo`, `totalFee`, `currency`, and `transactionId` -> MakePay event payload plus `paymentLink.uid` idempotency.
- Binance Pay webhook headers `BinancePay-Certificate-SN`, `BinancePay-Nonce`, `BinancePay-Timestamp`, and `BinancePay-Signature` RSA verification -> MakePay `x-makepay-signature` HMAC verification over the raw request body.
- Binance Pay `POST /binancepay/openapi/certificates` public-key lookup -> MakePay webhook secret configured in MakeCrypto.
- Binance Pay `POST /binancepay/openapi/v2/order/query` statuses `INITIAL`, `PENDING`, `PAID`, `CANCELED`, `ERROR`, `REFUNDING`, `REFUNDED`, `FULL_REFUNDED`, and `EXPIRED` -> MakePay payment-link lookup and normalized paid, pending, failed, refunded, and expired states.
- Binance Pay `POST /binancepay/openapi/order/close` and webhook `PAY_CLOSED` -> MakePay link expiry/cancellation or manual close workflow.
- Binance Pay `POST /binancepay/openapi/order/refund` with `refundStatus` `INITIAL`, `PENDING`, `CANCELLED`, and `REFUNDED` -> MakePay refund or manual support workflow.

## Agent prompt: inventory

You are migrating this repository from Binance Pay to MakePay. Search for Binance Pay API clients, `bpay.binanceapi.com`, `binancepay/openapi`, `/binancepay/openapi/v2/order`, `/binancepay/openapi/v2/order/query`, `/binancepay/openapi/order/close`, `/binancepay/openapi/order/refund`, `/binancepay/openapi/certificates`, `BinancePay-Certificate-SN`, `BinancePay-Timestamp`, `BinancePay-Nonce`, `BinancePay-Signature`, HMAC-SHA512, RSA webhook verification, `merchantTradeNo`, `prepayId`, `bizId`, `bizIdStr`, `checkoutUrl`, `qrcodeLink`, `qrContent`, `deeplink`, `universalUrl`, `orderAmount`, `currency`, `fiatAmount`, `fiatCurrency`, `supportPayCurrency`, `goodsName`, `goodsDetail`, `referenceGoodsId`, `buyerEmail`, `passThroughInfo`, `returnUrl`, `cancelUrl`, `webhookUrl`, `orderExpireTime`, `PAY_SUCCESS`, `PAY_CLOSED`, `PAY_FAIL`, `INITIAL`, `PENDING`, `PAID`, `CANCELED`, `ERROR`, `REFUNDING`, `REFUNDED`, `FULL_REFUNDED`, `EXPIRED`, `refundRequestId`, `refundStatus`, and Binance Pay webhook response handling. Return a file-by-file migration plan with the exact functions that create Binance Pay orders, sign requests, store prepay IDs, redirect buyers, render QR or deeplink checkout data, verify notifications, fetch order/refund status, close orders, refund orders, and reconcile order status. Do not edit files yet.

## Agent prompt: replace order creation

Implement MakePay payment-link creation in the existing Binance Pay order creation path. Use the official MakePay SDK for this stack when available; otherwise call `POST /api/partner/v1/makepay/payment-links`. Remove `BinancePay-Certificate-SN`, `BinancePay-Timestamp`, `BinancePay-Nonce`, and HMAC-SHA512 request-signing code from the new-order path. Map `merchantTradeNo` to `merchantOrderId`, `orderAmount` to `payload.amount`, `currency` to `payload.currency` or `payload.asset`, `fiatAmount`/`fiatCurrency` to the equivalent display or pricing currency configuration, `supportPayCurrency` to an exact asset only when the business must force buyer assets, `goodsName` to `label`, `goodsDetail` to `description`, `buyerEmail` to `clientEmail`, and `passThroughInfo`/`referenceGoodsId` to internal metadata. Store `paymentLink.uid` and `paymentLink.publicUrl`, and keep nullable legacy Binance Pay `prepayId` and `merchantTradeNo` fields for historical records.

## Agent prompt: replace hosted checkout and QR artifacts

Replace Binance Pay `checkoutUrl` redirects with MakePay `paymentLink.publicUrl`. Do not carry forward Binance `qrcodeLink`, `qrContent`, `deeplink`, `universalUrl`, `paymentInstructions`, `payerDetail`, or Binance app-specific URL fields as the primary order URL for new MakePay orders; those are provider-specific checkout artifacts. Find any frontend that renders Binance QR codes, deeplinks, universal links, or Binance app buttons. For one-off order checkout, replace it with MakePay hosted checkout, embedded checkout route, or modal script depending on the existing UX. If the product still needs a dedicated app deep-link experience, keep it behind a provider flag until all old Binance Pay orders are reconciled, then design a MakePay-native flow separately.

## Agent prompt: replace webhook verification

Replace Binance Pay order notification handling with MakePay webhook verification. For legacy Binance Pay notifications, preserve RSA verification until open Binance Pay orders are closed: read the exact raw request body, build `timestamp + LF + nonce + LF + body + LF` from `BinancePay-Timestamp` and `BinancePay-Nonce`, base64-decode `BinancePay-Signature`, select the Binance public key matching `BinancePay-Certificate-SN` from `/binancepay/openapi/certificates`, and verify SHA256withRSA before processing. Keep the required Binance response shape only for legacy Binance Pay endpoints: `{ "returnCode": "SUCCESS", "returnMessage": null }`. For new MakePay events, read the exact raw request body before JSON parsing, parse `x-makepay-signature`, verify timestamp tolerance and HMAC digest with the MakePay webhook secret, then process only trusted events. Treat `makepay.payment.status_changed` as the primary order reconciliation event and make updates idempotent by delivery ID and payment-link UID. For legacy Binance Pay notifications, use `bizIdStr` or `prepayId` plus `bizStatus` and `transactionId` for idempotency.

## Agent prompt: normalize statuses

Map legacy Binance Pay statuses explicitly during cutover. `PAY_SUCCESS` and query status `PAID` can complete the order only after amount, currency, `merchantTradeNo`, `prepayId`, and provider checks pass. `INITIAL` and `PENDING` should not grant goods. `PAY_CLOSED`, `CANCELED`, `EXPIRED`, and `ERROR` should close the payment without marking the order paid. `PAY_FAIL` is mainly direct-debit failure; route it to failed/manual-review logic if this integration used direct debit. `REFUNDING` should keep the order in a refund-pending state. `REFUNDED` and `FULL_REFUNDED` should update refund state without double-crediting or regressing fulfillment.

## Agent prompt: dual-run cutover

Add a migration flag so newly created orders use MakePay while existing Binance Pay orders can still receive notifications and order/refund polling until they are paid, closed, expired, cancelled, errored, refunding, refunded, fully refunded, or manually closed through the current business rules. Route callbacks by provider, keep provider-specific IDs separate, and add logs that include provider, order ID, payment UID, delivery ID, legacy Binance Pay `prepayId`, `merchantTradeNo`, `bizIdStr`, `bizStatus`, `transactionId`, `refundRequestId`, `refundStatus`, amount, currency, and normalized status. Remove Binance API identity keys, API secret keys, HMAC-SHA512 signing helpers, RSA certificate caching, `BinancePay-*` webhook verification, `checkoutUrl`/QR/deep link rendering, order polling, close-order code, and refund-order code only after there are no open legacy Binance Pay orders or refunds.

## Agent prompt: tests

Add or update tests for MakePay payment-link creation, failed authentication, webhook signature rejection, successful `makepay.payment.status_changed` handling, duplicate webhook delivery idempotency, legacy Binance Pay notification routing during cutover, Binance RSA signature rejection, certificate-serial mismatch, `checkoutUrl` replacement, QR/deeplink/`universalUrl` artifact removal, `INITIAL` and `PENDING` not granting goods, `PAY_SUCCESS`/`PAID` completion, `PAY_CLOSED` closure, `CANCELED`/`EXPIRED`/`ERROR` closure, `PAY_FAIL` direct-debit handling, `REFUNDING` pending refund state, `REFUNDED`/`FULL_REFUNDED` refund state, legacy query-order polling fallback, legacy refund polling fallback, and buyer redirect URL generation. Use mocked MakePay SDK/API responses; do not hit production APIs in tests.

## Verification checklist

- A new order creates exactly one MakePay payment link and stores `paymentLink.uid`.
- The buyer redirect uses `paymentLink.publicUrl` instead of Binance Pay `checkoutUrl`.
- New-order code no longer signs Binance Pay requests with HMAC-SHA512 or `BinancePay-*` request headers.
- New MakePay orders do not store Binance QR, deeplink, universal URL, or payment-instruction artifacts as order URLs.
- Webhook verification fails closed when `x-makepay-signature` is missing, stale, or invalid.
- `makepay.payment.status_changed` handling is idempotent by delivery ID.
- Completed orders cannot be regressed by delayed provider events.
- Legacy Binance Pay notifications keep RSA verification until cutover is complete.
- Legacy success, closed, failed, pending, cancelled, expired, error, refunding, refunded, and fully-refunded paths are explicitly tested.
- Existing Binance Pay orders and refunds still reconcile until the migration flag is removed.

Verification checklist

A new order creates exactly one MakePay payment link and stores paymentLink.uid.
The buyer redirect uses paymentLink.publicUrl instead of Binance Pay checkoutUrl.
New-order code no longer signs Binance Pay requests with HMAC-SHA512 or BinancePay-* request headers.
New MakePay orders do not store Binance QR, deeplink, universal URL, or payment-instruction artifacts as order URLs.
Webhook verification fails closed when x-makepay-signature is missing, stale, or invalid.
makepay.payment.status_changed handling is idempotent by delivery ID.
Completed orders cannot be regressed by delayed provider events.
Legacy Binance Pay notifications keep RSA verification until cutover is complete.
Legacy success, closed, failed, pending, cancelled, expired, error, refunding, refunded, and fully-refunded paths are explicitly tested.
Existing Binance Pay orders and refunds still reconcile until the migration flag is removed.
Production logs include provider, order ID, payment UID, delivery ID, legacy prepay ID, merchant trade number, business status, transaction ID, refund status, amount, currency, and normalized status.