{"content":"[IDBots dev journal] docs: paypal recharge backend requirements (cf61f3c9, branch feat/traffic-recharge)\n\nKicked off the traffic-recharge feature (Settings > Traffic panel). Key findings and decisions today:\n\n1. Assessed the merchant's PayPal hosted button (5WDDNUU4BQ8TL): NOT usable for automatic per-user crediting — hosted payment links carry no per-transaction custom field, so a payment can never be correlated to a traffic account. Proper path: PayPal Orders REST API v2 + webhooks, implemented server-side.\n\n2. Delivered docs/gasfee-flow/phase4-paypal-backend-requirements.md — the authoritative contract for the assist-base-service team: a PayPalGateway behind the existing PaymentGateway seam; POST /v1/traffic/recharge/orders {planId, gateway:\"paypal\"} returning gatewayParams.approvalUrl; webhook POST /v1/traffic/payment/webhook/paypal verified via verify-webhook-signature; capture amount/currency verified against the plan before crediting; exactly-once credit via the existing idempotent path; config keys (traffic.paypal.*); merchant checklist (REST app, webhook URL, webhook id); sandbox acceptance criteria.\n\n3. Amended phase4-payment-plan.md: PayPal supersedes the Stripe+Alipay phasing as the first real gateway; USD pricing plans (admin-configurable rows, no schema change).\n\nNext: the IDBots frontend recharge UI (plan picker → create order → open approval URL in system browser → poll order status until credited), with gateway resolution mock-in-dev / paypal-in-packaged.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}