One purchase can include several requests: loading InFlow configuration, creating or checking a payment, and requesting the seller’s product. Identify the destination, HTTP method, and operation that failed before changing credentials or retrying.

• An HTTP status describes the response to one request. A seller’s unpaid 402 is the expected payment challenge, not proof of a broken integration.
• An SDK error code describes a reported failure, such as an invalid parameter or a network problem. Read its message and associated endpoint; the code alone may not explain the cause.
• A transaction status describes the payment. A successful status lookup can report a failed payment, while a failed lookup can leave the payment outcome unknown.

Keep the original purchase references when payment may have started. An error during receipt parsing or product delivery does not establish that payment failed.

First check whether the failing request went to InFlow or to the seller’s service. An InFlow API key authenticates an InFlow API call. It does not replace the login or credentials required by the seller’s endpoint.

Follow Accounts and environments for setup. A Seller account can also act as a buyer; buying does not require replacing a valid Seller account with a Developer account. For initialization details, use the Go, Node.js, Python, or Rust guide.

No acceptable payment option

Compare what the seller advertised with what your buyer supports and permits. Check the protocol, method, currency, network, amount, and your application’s selection rules. Also check the funding or account prerequisites for the selected method.

Do not remove spending limits or network restrictions just to obtain a match. Correct a mistaken filter only after confirming the intended purchase. If no supported option satisfies those rules, stop without paying. See Choose payment options.

If the seller cannot advertise a method, inspect its configuration error and readiness. Stripe payments, Linked cards, and Visa CARD have distinct prerequisites. Support for one does not establish readiness for another.

The paid request still returns 402

Read the final response’s payment error or problem details. A repeated 402 can result from an invalid credential, changed purchase terms, or a payment failure. It does not identify one universal cause.

• Confirm that the buyer sent the credential using the selected protocol’s expected header, and that a proxy did not remove it.
• Compare the destination, HTTP method, body, and purchase terms with the request the buyer intended to pay. Check any reported expiry or credential mismatch.
• On an endpoint supporting both protocols, confirm that the selected payment path handles the paid request. The application must not require another payment through the other protocol.
• If payment was already submitted, check its status before generating a replacement credential or starting another purchase.

The MPP buyer guide and x402 buyer guide describe credential submission. Accept both protocols explains routing a combined endpoint without charging through both paths.

Read the existing transaction and any action returned with it. Pending does not always mean the owner needs to approve. Payment processing, approval, and card verification are different steps.

• If an approval is waiting, open the matching buyer account’s Sandbox Approvals or production Approvals. Check the existing request rather than creating another to get a new notification.
• If the transaction supplies a card-verification action, present the returned link to the buyer. Follow Complete a requested card check and then read the same transaction again.
• If payment is processing without a requested buyer action, continue checking the existing transaction. Respect returned retry guidance and use a bounded wait.
• If a status read fails, check its credentials, environment, and transaction ID. Retry the read when appropriate; a failed lookup does not establish that no payment occurred.

An HTTP request timeout and an approval-wait timeout measure different operations. Increasing one does not necessarily change the other. Inspect the settings for your chosen SDK before adjusting them.

Stopping local waiting does not prove remote cancellation. Some payment helpers attempt cleanup, but the result still needs to be checked. Cancellation does not refund a completed payment. Use Status and recovery for the recovery procedure, including a creation request that failed before returning an identifier.

If a request works directly against your application but fails through its public hostname, compare the unpaid responses first. This checks the deployment path without repeatedly purchasing the resource.

• Compare status codes and payment headers. Check the proxy’s request and error logs at the same timestamp. An HTML proxy error is different from a payment error returned by the application.
• Check both incoming request-header limits and outgoing response-header limits. Large combined MPP/x402 offers can exceed a response limit even when the application generates a valid challenge. See Check response-header size before changing proxy settings.
• Check whether a redirect changes the destination. Use the intended final endpoint and preserve credential scoping; do not enable indiscriminate forwarding of payment or authentication headers.
• If only a browser fails, inspect its network panel for preflight or cross-origin restrictions. Check allowed request headers and exposed payment-response headers. A response visible to a command-line client may still be inaccessible to browser code.
• For connection or certificate failures, check hostname resolution, the certificate chain, and outbound network access from the application’s environment. Fix the connection rather than disabling certificate verification.

After correcting the request path, verify it in Sandbox. An unpaid request cannot test receipt preservation or paid delivery; those need a controlled purchase after any earlier payment outcome is resolved.

Check payment and delivery separately. If payment settled but the response was lost, recover the original report, download, or order. Do not ask the buyer to pay again merely because your application could not read the response.

• Match the payment reference to the application’s purchase record. Confirm the requested product and inputs, not just an identical amount.
• Check whether the handler completed, whether the result was retained, and whether the response reached the buyer. A success status or decoded receipt alone does not establish correct delivery.
• If the receipt is missing, compare the application’s response with the response received through the proxy. Check response construction and header forwarding before blaming settlement.
• If payment status remains unknown, keep the purchase unresolved. Read its status or obtain help instead of turning a delivery error into another charge.

Follow Deliver paid results for saved results and duplicate fulfillment. Recovery must retain access checks; knowing a purchase reference must not grant another buyer access to private content.

Keep enough information to identify the failed operation without exposing credentials. Review error bodies and logs before sharing them; they can contain request data even when sensitive headers are omitted.

• Application and SDK versions, runtime version, Sandbox or production, and the selected protocol and payment method.
• The timestamp with timezone, HTTP method, and destination. Remove sensitive path or query values while retaining enough structure to identify the endpoint.
• The exact error code and sanitized message, HTTP status when a response arrived, and request ID when supplied. Keep the original transaction reference privately for payment investigation.
• Which steps succeeded, which step failed, and whether the direct application request behaves differently from the deployed path.
• A small reproduction using test data and placeholder credentials. Include the relevant configuration without secrets.

Field names vary by SDK. For example, Node.js InflowApiError in both MPP and x402 exposes code, httpStatus, endpoint, and an optional requestId. Read these fields alongside the message; do not assume the message contains every diagnostic detail.

Ask for help in Discord with the sanitized summary. Keep account and transaction identifiers out of public posts when they identify a private purchase. Arrange a private support exchange for those details. Never share API keys, cookies, signed payment credentials, card data, or personal information in a public report.