Frequently asked questions

Answers about 302 routing to bank official H5 checkouts, CNAME setup, micro-payment verification, binding changes, and troubleshooting. If anything conflicts with your account page or published rules, the latest on-site notice prevails.

First time using Domain Wallet—what should I know?

Domain Wallet uses public DNS and 302 redirects to route your top-level domain to your bound bank or licensed institution official H5 checkout. Before starting, confirm:

You control DNS for the domain and it is in good standing at the registrar
CNAME points to 302wallet.com
You registered in the merchant portal and submitted a checkout URL
You completed random micro-amount verification or TXT fallback

We never touch or retain payment flows—all funds stay within the licensed checkout.

How do I set up CNAME and bind a checkout?

We do not register or host your domain. Steps:

At your registrar, add CNAME for @ (and recommended www) to 302wallet.com
Wait for DNS (usually 5–15 minutes, registrar-dependent)
Log in to the merchant portal, pass captcha, submit domain and bank H5 checkout URL
Complete micro-payment verification; routing syncs to resolvers

See CNAME guide; for DNS verification see TXT guide.

What is Domain Wallet vs. aggregate payment?

Domain Wallet is a pure routing layer: 302 redirects at the W3C / ICANN protocol level—not a payment institution, clearing house, or custodian.

You hold domain sovereignty and checkout URL
Bank/licensee holds clearing and funds
We only maintain immutable domain → checkout mapping

What is micro-payment "reverse handshake" verification?

To prevent hijacking, new or changed bindings require a micro-payment: within 5 minutes the system assigns a random amount (e.g. 0.07 CNY). Pay on your checkout, then enter the exact amount in the portal. On match, the binding activates and syncs to public resolver Redis.

If micro-payment is not possible, use TXT verification.

Why can bindings not be UPDATEd?

Bindings are physically locked: UPDATE is rejected. To change a checkout URL, complete 2FA via your phone, DELETE then INSERT, and re-verify. This prevents silent mid-chain rerouting attacks.

Can I bind multiple domains to different checkouts?

Yes. Each TLD / Punycode is a separate record (unique domain_key). One merchant account can manage multiple bindings in "My bindings".

What happens when customers visit my domain?

Resolver nodes read Redis routing and 302 redirect to your bound official H5 checkout. We do not proxy order pages or intercept sensitive payment parameters.

How long until CNAME propagates?

Most registrars: 5–15 minutes globally; long TTL or some networks may take hours. Use nslookup or online DNS tools to confirm 302wallet.com. Portal validation may fail before DNS is live.

How to change or unbind a checkout URL?

Log in to the merchant portal
Select domain; "Change URL" deletes old record and inserts new (no UPDATE)
Complete micro-payment verification again
Unbind runs DELETE and clears resolver Redis

Why is redirect broken or checkout won't open?

CNAME not live or pointing elsewhere
Binding not activated (no micro-payment / TXT verification)
Bank checkout URL changed, risk controls, or geo restrictions
Domain expired or suspended by registry
Merchant deleted binding or DNS records by mistake

Follow Support & anti-fraud guide for Punycode and TLS checks; see CNAME guide for DNS issues.

How to prevent phishing and fake checkouts?

Train customers to trust your top-level domain in the address bar; after redirect, verify the bank/licensee TLS certificate. Never pay via unknown links. We do not embed checkouts—we only 302 at the protocol layer.

Does 302 affect SEO?

Domain Wallet targets offline collection and branded checkout entry, not content sites. 302 is typically not an SEO primary-site strategy; if the domain also hosts a website, separate content and checkout on www or subdomains—consult your SEO advisor.