WeChat Pilot

Updated 9 September 2026

Verified Status

On 7 September 2026, the tester completed a real WeChat -> Teams -> WeChat round trip. The customer enquiry arrived in Unassigned, the authorized employee claimed it, and Send to WeChat returned Accepted. The tester confirmed receipt and replied "WeChat received". The same case retained its owner and returned to Mine / Needs Reply. WhatsApp, LINE and WeChat are visible in the same queue.

The implementation uses the Official Account test sandbox, not WeChat Customer Service/WeCom. Sandbox success does not establish 99 Venture's production account eligibility. No new Azure resource or paid service was created for this channel.

Setup for a New Sandbox

1. Sign in manually at the Official Account Test Portal using WeChat on the tester's phone. Follow the sandbox using its separate QR.
2. Check its permissions table lists customer-service sending. The observed sandbox listed 500,000 daily customer-service calls and 2,000 standard token calls; these are account-screen limits, not unlimited messaging rights.
3. Save AppID, AppSecret and the gh_ account identity privately. Configure WECHAT_APP_ID, WECHAT_APP_SECRET, WECHAT_ACCOUNT_ID and a locally generated random WECHAT_VERIFY_TOKEN. All four are required together.
4. Use Shared Setup for Teams and hosting. Back up only the isolated application, consistent database, environment and dedicated nginx site.
5. Deploy the runtime and proxy /webhooks/wechat over owned HTTPS. Test the GET challenge. The server must echo echostr only after signature verification.
6. Enter the URL and matching Token in the sandbox, then Submit. The tested sandbox uses plain XML over HTTPS. Do not select encrypted mode: it is not implemented and is explicitly rejected.
7. Send a fictional enquiry from the phone. In Teams -> OCDIT -> Inbox, pick up the case, reply with Send to WeChat, confirm receipt and send a follow-up.
8. Verify the same case returns to Mine / Needs Reply. Record results without including actual credentials, customer IDs or tenant identifiers in deliverables.

Browser automation is blocked on the sandbox and the inspected documentation page by site-safety policy. Use manual portal steps and user-supplied document exports; do not use alternate browser/tool workarounds.

Reply Rules and Limits

• A customer message opens a 48-hour reply window. The supplied service-message reference lists five replies. The pilot conservatively reserves five attempts per conversation in a rolling 48 hours, including failed/uncertain attempts. It does not assume incoming messages replenish the provider quota.
• Replies are limited to 2,000 UTF-8 bytes. Text only; media is not downloaded.
• The stable-token endpoint receives POST JSON with client_credential, appid, secret and force_refresh=false. The process caches tokens using expires_in and coalesces concurrent refreshes. Live token access returned a 7,200-second expiry.
• The send API returns errcode=0 for acceptance, without a message ID or read receipt. The stored wechat-accepted marker is local, not a provider delivery ID.
• Ambiguous sends are quarantined and never retried automatically. Do not reset failed/uncertain jobs blindly or resend merely because no receipt is available.
• No transfer_customer_service response is used: that would hand the conversation to WeChat's native support system and can divert callbacks away from OCDIT.

Security and Production Gaps

The sandbox route accepts plain XML over TLS, verifies query signature/freshness, checks destination, restricts XML to flat fields without DTDs/external entities, preserves 64-bit message IDs as strings and deduplicates messages. An observed signature is bound to its first accepted body digest. The query signature itself is not an authenticated body digest. Encrypted-mode support and its validation are required before treating this demonstration as production-ready.

Thirteen local checks cover these behaviours, token failures, channel isolation, reply limits and uncertain outcomes. Live multi-user handover, WeChat note isolation, media, unsubscribe/unsend handling, retention, quota recovery, restore drills and production verification remain untested or unimplemented. No customer identities are merged across channels. Callback-record retention follows the unresolved pilot retention work.

Evidence Sources

The tester supplied official-page exports named getStableAccessToken.pdf, Send customer service messages.pdf, Customer Service Messages Introduction.pdf, Receive regular messages.pdf, forward the message to customer service.pdf, Service API Call Instructions.pdf and Open API.pdf, plus screenshots of the callback verification algorithm. These were treated as reference material only. Live token, callback and phone tests supplement the documentation evidence.