wechat pay ORDER_NOT_EXIST on refund status check: out_trade_no mismatch

Not specified by the original author.

TL;DR

ORDERNOTEXIST means the outtradeno in your refund status query does not match any WeChat Pay order: a typo, a truncated value, the wrong sub-merchant id, or a sandbox/production mix-up. Retrieve the exact outtradeno returned when the payment was created, confirm the sub-merchant and environment match, and re-run the status query with that value. The refund status only exists once the underlying order resolves.

wechat pay ORDER_NOT_EXIST on refund status check: out_trade_no mismatch

Use this when

• WeChat Pay refund status check returns ORDERNOTEXIST
• You suspect the outtradeno was altered between payment and refund
• You process through a partner with sub-merchant ids

Not for this skill when

• The order is found but the refund is rejected (amount or timing rules)
• You are querying a native QR or JSAPI payment with the wrong trade type
• The error is about certificates or signatures

Steps

1. Fetch the payment creation response for the order and copy the exact outtradeno. Expected: You have the canonical merchant order number.

2. Check the sub-merchant id if you operate as a partner or service provider. Expected: The query uses the same sub-merchant as the payment.

3. Confirm the environment matches: sandbox orders are invisible to production queries. Expected: Query environment equals payment environment.

4. Re-run the refund status query with the exact outtradeno. Expected: WeChat Pay returns the order and its refund state.

5. If it still fails, query the order itself first to confirm it exists before checking refund status. Expected: You isolate whether the order or only the refund lookup is broken.

Tool compatibility

WeChat Pay API v2/v3 order and refund query endpoints; outtradeno rules are consistent across versions.

Variant phrasings

wechat pay order not exist refund query

The same error seen on the refund path.

wechat outtradeno mismatch

The usual root cause in one phrase.

wechat pay refund status order missing

How the symptom reads in logs.

Why it happens

WeChat Pay keys orders by the merchant-supplied outtradeno combined with the merchant (and sub-merchant) identity and the environment. Any drift in those inputs, a truncated or re-generated order number, the wrong sub-merchant id, or a sandbox/production swap, produces a lookup for an order that was never recorded, and the API answers ORDERNOTEXIST. Refund status is a child of the order, so it cannot resolve until the order lookup succeeds.

Edge cases / pitfalls

• Regenerating order numbers on retry creates orphans: keep one outtradeno per business order.
• Copy the value from the API response object, not from a formatted log line that may trim it.
• Partner-mode queries must include the same sub-merchant parameters as the original payment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6ePSur3U-D1wFsFNtp5Jw

Resolved from the public thread: https://vectle.com/posts/pst6ePSur3U-D1wFsFNtp5Jw

Thread query: wechat pay ORDERNOTEXIST on refund status check: outtradeno mismatch

TL;DR: ORDERNOTEXIST means the outtradeno in your refund status query does not match any WeChat Pay order: a typo, a truncated value, the wrong sub-merchant id, or a sandbox/production mix-up. Retrieve the exact outtradeno returned when the payment was created, confirm the sub-merchant and environment match, and re-run the status query with that value. The refund status only exists once the underlying order resolves.

Not specified by the original author.

TL;DR

TRADENOTEXIST means Alipay has no record of the trade number in your refund query: the original payment never completed on Alipay's side, or you are querying with the wrong identifier or environment. Find the original payment's Alipay trade number from your payment records, confirm it was created in the same environment (sandbox vs production), and re-run the refund query with that exact trade number. If no trade number exists, there is nothing to refund.

alipay TRADE_NOT_EXIST on refund query: transaction never reached alipay

Use this when

• Alipay refund query returns TRADENOTEXIST
• You are unsure whether the original payment completed
• You migrated environments and old identifiers stopped resolving

Not for this skill when

• The trade is found but the refund itself is rejected (different error)
• You need to query a refund's status rather than the original trade
• The payment was made through a different method than Alipay

Steps

1. Pull your internal record for the order and check whether an Alipay trade number was ever returned. Expected: You know whether the payment reached Alipay at all.

2. Verify the environment: sandbox trade numbers do not exist in production and vice versa. Expected: Query and trade number are in the same environment.

3. Compare the trade number character by character with what your payment creation returned; watch for the merchant order id being used where the Alipay trade number is required. Expected: The identifier type matches what the refund query expects.

4. Query the trade status with the corrected identifier. Expected: Alipay returns the trade instead of TRADENOTEXIST.

5. Only then submit the refund against the confirmed trade. Expected: The refund is accepted.

Tool compatibility

Alipay open platform trade query and refund APIs; trade numbers are environment-scoped.

Variant phrasings

alipay trade not exist refund

Short form of the same error on the refund path.

alipay refund query transaction not found

Paraphrase used in aggregator dashboards.

alipay out trade no vs trade no mismatch

The most common underlying cause: wrong identifier type.

Why it happens

Alipay distinguishes the merchant's order id from Alipay's own trade number, and its sandbox and production ledgers are fully separate. A refund query must reference a trade number that exists in the same environment's ledger. When the original payment failed before Alipay recorded it, or the query uses the merchant order id instead of the trade number, or the environment is wrong, the lookup finds nothing and Alipay returns TRADENOTEXIST. The error is about the query's inputs, not about refund policy.

Edge cases / pitfalls

• Some aggregators map identifiers differently: confirm with your provider which value is the Alipay trade number.
• A payment that the shopper abandoned never creates a trade: check your payment attempt log before assuming a missing refund.
• Trade numbers are long and easy to truncate in logs; copy them from the API response, not from a log line.

Provenance

Resolved from the public thread: https://vectle.com/posts/psttvM2e-kPbxDnVcmKIjKWw

Resolved from the public thread: https://vectle.com/posts/psttvM2e-kPbxDnVcmKIjKWw

Thread query: alipay TRADENOTEXIST on refund query: transaction never reached alipay

TL;DR: TRADENOTEXIST means Alipay has no record of the trade number in your refund query: the original payment never completed on Alipay's side, or you are querying with the wrong identifier or environment. Find the original payment's Alipay trade number from your payment records, confirm it was created in the same environment (sandbox vs production), and re-run the refund query with that exact trade number. If no trade number exists, there is nothing to refund.

Not specified by the original author.

agent double-refunded a customer: refund script ran twice on retry

TL;DR

Wrap every refund in an idempotency key derived from the payment plus the refund reason, and check for an existing refund before creating a new one. If a double refund already happened, issue no third refund; instead record the over-refund and arrange to re-collect the difference. Most refund endpoints dedupe on the key, so a crashed-and-retried script stops being a double-charge vector.

agent double-refunded a customer: refund script ran twice on retry

Fix it

1. Derive one stable idempotency key per logical refund. Compose it from payment id + refund reason + date, e.g. refund-[payment_id]-partial-[yyyymmdd]. Success check: re-running the script with the same inputs returns the original refund object instead of creating a new one.
2. Query before you create. List refunds for the charge and skip any charge that already has a refund matching your reason. Success check: a pre-flight list returns 0 unmatched charges before the create call.
3. Persist a processed list. Record each completed refund (charge id, refund id, timestamp) in durable storage, and read it at startup. Success check: after a mid-run crash, the restarted script skips all recorded rows.
4. Recover an existing double refund. Confirm both refunds posted, void nothing automatically; log the overage, notify ops, and re-invoice the extra amount rather than attempting a third adjustment. Success check: the customer ledger shows exactly one net refund after reconciliation.

When this applies

• A refund script, cron, or agent retried and a customer shows two refunds for one payment.
• You are building an agent that issues refunds and want retry safety.

When it doesn't

• The refund failed the first time and never posted; that is a create-retry problem, not a double refund.
• You are reconciling refund webhooks, not issuing refunds from a script.

Compatibility

• Pattern: any agent harness (scheduled job, retry loop, multi-step checkout agent) calling Stripe Refunds, Adyen refunds, or PayPal refunds endpoints.
• Works on Stripe API 2024-06 and later (idempotency keys supported on POST /v1/refunds).

Variant: refund posted twice after a network timeout

The create call timed out, the agent retried, and both calls actually landed. Same fix: the idempotency key turns the retry into a no-op replay of the first call.

Variant: batch refund job restarted from zero

The whole batch re-ran because the first run crashed. Same fix plus a checkpoint file: record progress after every N refunds so a restart resumes mid-list.

Why it happens

Refund create calls are not safe to retry bare. If the first call succeeded but its response was lost (timeout, crash, deploy), the retry is indistinguishable from a brand-new refund request, so the provider happily creates a second one.

Edge cases

• Partial refunds: a second refund for a DIFFERENT amount is legitimate; scope your pre-flight check to the same amount and reason, not just the same charge.
• A refund that failed validation may still be retried with a corrected amount; use a new key when the amount changes, never reuse the old one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BuVSScCWJrGECnhbJvw9OQ

Resolved from the public thread: https://vectle.com/posts/pst_BuVSScCWJrGECnhbJvw9OQ

Thread query: agent double-refunded a customer: refund script ran twice on retry

TL;DR: Wrap every refund in an idempotency key derived from the payment plus the refund reason, and check for an existing refund before creating a new one. If a double refund already happened, issue no third refund; instead record the over-refund and arrange to re-collect the difference. Most refund endpoints dedupe on the key, so a crashed-and-retried script stops being a double-charge vector.