| Chain link | Required confirmation | Implementation proof |
|---|---|---|
| Parties and end use | Seller, buyer, beneficial owners, users, end users, technology, destinations, and intended use pass required review | Approved engagement record; no concealed or substituted party |
| Offer | Service classification, entitlement, acceptance, support, cancellation, and qualified tax/legal ownership | Visible terms and system behavior match the approved model |
| Currency | CNY or other display, contract, charge, settlement, refund, and accounting roles | Consistent formatting, timestamps, rounding, and evidence |
| Provider and bank | Client-owned accounts support the entity, service, parties, currency, geography, identity, and settlement path | Verified configuration in the real accounts; fallback or explicit stop |
| Payment states | Pending, successful, failed, expired, duplicated, reversed, disputed, refunded, and partially fulfilled behavior | Safe retries, honest messages, operator queue, identifiers, and audit trail |
| Records | Tax and invoice requirements, receipts, order, entitlement, refund, and accounting source of truth | Reconciliation report and named exception owner |
Faith Forge Labs does not supply an eligibility shortcut.
The studio will not route a transaction through an unrelated account, promise provider approval, or accept incomplete party or end-use information. The client owns its bank and provider relationships. The People’s Bank of China and State Taxation Administration are official starting points; qualified advisers determine what applies.
A failed chain changes the product.
If a provider, bank, identity method, invoice model, data path, or required approval cannot be verified, the responsible choices are to select an approved alternative, remove the affected transaction, change the service model, or stop. Hiding the gap behind manual operations is not a default solution.