Pay for an 胖狐中转 Platform Order

Create or refresh a payment session for a Pending order. The payment action will access the payment channel and may change the order status. You must confirm the order ID, amount, and payment method before calling.

API Overview

Item Content
Method POST
URL https://fox.platform.acedata.cloud/api/v1/orders/{order_id}/pay/
Authentication Hosted redirect payments can be anonymous; other methods require a login session or Account Token
Body JSON; unpaid orders must provide pay_way

Boundaries of Anonymous Payment

Anonymous access is intended for scenarios where the login session is lost after opening a copied payment link. It does not require, and should not carry, a long-term Account Token. Anonymous calls:

  • Only allow hosted redirect payment methods configured by the server;
  • Always use the desktop payment page;
  • Cannot claim zero-price orders;
  • Are subject to IP and per-order rate limiting;
  • Return a minimal order projection, without account, Application, or internal metadata.

Authenticated callers must be the order owner or a super administrator. Methods requiring user context, such as X402 and reward redemption, cannot be called anonymously.

Request Examples

export ORDER_ID='Your Pending order ID'

curl -X POST \
  "https://fox.platform.acedata.cloud/api/v1/orders/${ORDER_ID}/pay/" \
  -H 'Content-Type: application/json' \
  -d '{"pay_way":"Stripe"}'

Payment methods requiring authentication:

export PLATFORM_TOKEN='Your account token'

curl -X POST \
  "https://fox.platform.acedata.cloud/api/v1/orders/${ORDER_ID}/pay/" \
  -H "Authorization: Bearer ${PLATFORM_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{"pay_way":"X402"}'

pay_way uses actual values supported by the order model, such as WechatPay, AliPay, Stripe, Card, Airwallex, X402, PayPal, AppleIAP, Reward, and BankTransfer. Not every value is available for anonymous requests or every site.

Response Description

A successful response is the updated order object, which usually provides the next-step entry through pay_url; different payment methods may also return information required by the client to continue payment in controlled fields. Anonymous responses use a minimal field allowlist, while authenticated owners receive full details.

Do not rely on legacy field names such as payment_url, qr_code_url, or payment_method; the current Order contract uses pay_url and pay_way.

iOS In-App Purchase

The logged-in order owner can pass pay_way: "AppleIAP". This request updates the pending payment order based on the selected plan's metadata.apple_price and clears discounts. It does not charge, grant credits, or return a payment link. Legacy pending payment orders should complete this step before initiating Apple native payment. Only one Usage plan with a configured Apple product and price is supported; unsupported plans or batch orders return 400.

After Apple native payment, submit transaction_id through /api/v1/orders/{id}/apple-verify/ to complete server-side verification and credit issuance. The number of credits comes from the plan; the amount uses Apple's independent preset USD price, without stacking membership discounts or site markups. The local-currency charge amount in other regions is subject to the Apple confirmation page.

Errors and Retries

  • The order is not Pending: returns 400; do not repeatedly create payment sessions.
  • pay_way is not provided: non-zero-amount orders return 400.
  • An anonymous call uses a disallowed method or a zero-price order: returns 403; retry as the owner after logging in.
  • Authenticated but not the order owner: returns 403.
  • Payment channel failure: do not blindly resubmit; first query the order details, confirm it is still Pending, and then retry.