alipay TRADE_NOT_EXIST on refund query: transaction never reached alipay

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.

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

You cannot refund a transaction that has not settled yet. Void it instead: voiding cancels the authorization and releases the hold, which is the correct reversal for unsettled transactions. Only use refund after settlement.

91507 cannot refund a transaction that is not settled

Use this when

• A Braintree refund call returns error 91507.
• The transaction is authorized or submitted for settlement but not settled.
• You need to choose between void and refund in code.

Not for this skill when

• The transaction is settled and the refund still fails. That is a different error.
• You want to reverse a partial amount on an unsettled transaction. Void is all-or-nothing.

Steps

1. ('Check the transaction status. Verify: it is authorized or submittedforsettlement, not settled.', 'Call void on the transaction instead of refund. Verify: the void succeeds and the authorization is released.', 'Tell the customer the hold will drop off, usually within a few business days per their bank. Verify: support has the right expectation set.', 'In code, branch on status: void if unsettled, refund if settled. Verify: the branch is tested with both states.', 'If you need partial reversals on unsettled transactions, settle first is not an option; void the whole thing and re-charge the right amount. Verify: finance approves the re-charge.')

Variant phrasings

braintree 91507

Code-first search.

braintree void vs refund

Concept search.

cannot refund unsettled transaction braintree

Symptom search.

Compatibility: Braintree transaction API, void and refund operations, all SDK versions.

Why it happens

Authorization and settlement are two steps: authorization holds the money, settlement moves it. A refund returns moved money, so it needs settlement to have happened. A void cancels the hold before money moves. 91507 is Braintree enforcing that distinction: refunding an authorization would be returning money that never left. The void path is faster for the customer too, since no money movement needs unwinding.

Edge cases / pitfalls

• Void is all-or-nothing. There is no partial void.
• A transaction submitted for settlement can still be voided until the settlement batch runs. Act quickly.
• Once settled, void is no longer possible. The branch must check status at call time.
• Customer messaging differs: "the hold will drop off" for voids vs "the refund is on its way" for refunds.

Provenance

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

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

Thread query: braintree error 91507: cannot refund a transaction that is not settled

TL;DR: You cannot refund a transaction that has not settled yet. Void it instead: voiding cancels the authorization and releases the hold, which is the correct reversal for unsettled transactions. Only use refund after settlement.