Payment and settlement
The buyerโs charge, merchant revenue and wallet balance are separate values. Use merchant orders and wallet transactions to confirm settlement.
Channels and merchant settings
Products can use enabled platform TDC or online-payment channels, subject to their payment settings and the available quote.
In Merchant Center โ Payment and settlement, configure guest purchases and inspect the platform-assigned hold, guarantee deposit and fee credit. TDC always requires buyer sign-in, even if guest purchases are enabled.
Merchant-owned Stripe requires a platform-configured fee rate. Setup has two steps:
- Save your Stripe account details to obtain the payment notification URL.
- Add that URL to Stripe Webhook settings with
checkout.session.completedandcheckout.session.async_payment_succeeded. Copy its Signing Secret into the merchant page and save to enable payments.
Buyers cannot use the channel until setup is complete. Available TDC or approved credit must fund the platform fee; insufficient funding or unavailable credit rejects the transaction. Merchant-owned channels receive funds directly without duplicate TDCloud wallet revenue.
Buyer charge versus merchant revenue
The product net amount is the product total minus discounts. Platform channels settle merchant revenue in TDC based on this net amount. The buyerโs payment fee is not merchant revenue.
For example, an order paid in TDC:
| Item | Example amount |
|---|---|
| Product total | 10 TDC |
| Discount | 1 TDC |
| Product net amount | 9 TDC |
| Buyer fee | 0.27 TDC |
| Buyer payment | 9.27 TDC |
| Merchant product revenue | 9 TDC |
This example explains the fields; it does not establish a fixed fee rate. Use the actual order quote.
For an online channel in another currency, the buyer pays in that currency and merchant revenue is settled in TDC using the orderโs saved exchange-rate snapshot. A payment of 10 USD does not mean a credit of 10 TDC. Do not recalculate historical revenue using todayโs rate.
Confirming a credit
Check the merchant orderโs revenue information, then match its order number with the wallet transaction and balance change. A merchant does not need to top up just to create a wallet before the first sale.
If payment is confirmed but no revenue record appears, report the order number to the platform. Do not change sales counters, repeat payment or manually increase balances to compensate.
Settlement and delivery
Delivery can remain pending after payment confirmation and revenue settlement. A fulfillment retry does not mean the buyer needs to pay again. See Merchant orders and reconciliation.
There is no withdrawal or automatic-refund procedure in this guide because the public interface does not yet offer those complete flows. Ask the platform how such requests are handled.
General collection for external orders
For your own business orders, use General merchant collection OpenAPI to create by amount without TDCloud catalog products or buyer OAuth authorization. Your server can supply return_url; TDCloud returns the buyer after confirmed payment. Your server must query payment or verify a status notification before updating the business order idempotently.
Platform-channel collection settles TDC at the creation-time rate. The platform assigns a 0โ30 day hold per merchant; zero is immediately available. Complaints prevent release of that orderโs frozen sales funds. Confirmed losses use those funds, the guarantee deposit, available balance and outstanding recovery balance in sequence. Nonrefundable fees can make losses exceed frozen funds. Verified refunds and chargebacks retain the original payment event and are recorded by the platform.
Administrator-assigned Stripe test channels do not charge real buyer funds, but normal wallet TDC posting, holds and fulfillment can still run. Administrators maintain test products and fulfillment. Merchant and paying-user restrictions combine as follows:
| Configuration | Transactions allowed on this test channel |
|---|---|
| Merchants only | All buyers at the specified merchants |
| Merchants and paying users | Specified paying users at the specified merchants; both conditions must match |
| Paying users only | Specified paying users at any merchant |
| Neither | No debug access |
With multiple identifiers, match any merchant in the merchant list and any user in the user list. A paying-user restriction requires TDCloud sign-in even when guest checkout is enabled. Merchant-only configuration follows the merchantโs guest policy. Wallet recharge has no merchant context, so it requires a user-only configuration. Administrator identity does not grant access. These conditions govern the selected test channel; they do not convert other merchant channels into test payments. See General merchant collection for return URLs and payment confirmation.
External systems may create amount-based collection orders without specifying a channel, allowing buyers to choose an available method at TDCloud checkout. Specify a channel to restrict an order to one method. Checkout displays payment details, amount and countdown; reconciliation and settlement records remain on the merchant server. Starting payment locks the method, and refreshing does not create a separate attempt.
Optional collection notifications and replay
In Merchant Center โ Payment and settlement, configure a public HTTPS receiver under Collection status notifications. Notifications are off by default; creation and server-side lookup still work. Saving an endpoint generates a separate signing secret, displayed once. Store it on your server, implement verification, then enable default notifications.
New collection orders can inherit these defaults. Creation can instead specify a per-order URL/key pair or disable notifications with notify_enabled: false. Changing the endpoint, disabling defaults or rotating the key affects new orders only. Historical notifications and replays keep their creation-time endpoint/key; retain old keys in your receiver.
On the same page, enter a TDCloud collection order number under Collection notification records to inspect order status, notification event IDs, cumulative attempts, HTTP results and recent attempt details. Each request waits at most 8 seconds. Each cycle permits 10 attempts (one initial attempt and nine retries with increasing delays). Once exhausted, choose Replay notification to requeue the event. History and cumulative counts remain available.
Verify and persist events reliably before returning HTTP 2xx as acknowledgement. Handle repeated events idempotently. Delivery failure does not reverse payment or wallet settlement. See General merchant collection for signatures, retry intervals and parameters.