Skip to Content
๐Ÿช Merchant GuidePayment and settlement

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:

  1. Save your Stripe account details to obtain the payment notification URL.
  2. Add that URL to Stripe Webhook settings with checkout.session.completed and checkout.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:

ItemExample amount
Product total10 TDC
Discount1 TDC
Product net amount9 TDC
Buyer fee0.27 TDC
Buyer payment9.27 TDC
Merchant product revenue9 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:

ConfigurationTransactions allowed on this test channel
Merchants onlyAll buyers at the specified merchants
Merchants and paying usersSpecified paying users at the specified merchants; both conditions must match
Paying users onlySpecified paying users at any merchant
NeitherNo 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.

Last updated on