RCS — TEST/FAKE notifications and OTP

RCS is available as a synthetic staging laboratory. Google provider registration is pending. No real RCS agent, credential, phone capability lookup, webhook or outbound connection is configured. A successful simulation does not prove delivery to a handset or availability in a country.

Cabinet

• Open an external project's TEST environment and select RCS in Options & channels to reveal its guide. Select Verify to reveal the OTP laboratory. These checkboxes control visible settings; they do not activate delivery.
• Use the TEST balance form to quote and submit an RCS service notification. API notifications use a versioned RCS template and a synthetic destination.
• Select RCS FAKE in Verify, create a challenge for test:customer-001, read the protected FAKE inbox and check the code. A configured WhatsApp/Telegram control can coexist with this separate FAKE laboratory.
• Notification journal includes both service notifications (TRANSACTION) and RCS verification admissions (AUTHENTICATION). The latter displays verificationStatus separately from the accepted simulation. Resends update the same verification entry and count, rather than creating another success fee. There is no handset delivery evidence.
• Filter the journal and Usage by RCS, source and creation period. RCS costs include notification holds and RCS Verify holds. Notification traffic counters count queue notifications; Verify challenges are shown in Verify and the journal. CSV includes active filters; journal CSV also preserves the product, traffic type and authentication state. It never exports codes or bodies.

API: service notification

Use https://localhost:8444 from your backend with a TEST key carrying notifications:write/read. Register an RCS template in the cabinet: no title, countries or push data; body up to 1,600 characters after rendering and any branding footer. This is the platform sandbox limit, not a Google tariff or capability statement. New sandbox projects get an enabled RCS queue with capacity 1,000; existing projects can bootstrap it with one cabinet TEST send, unless an operator explicitly disabled it. The API respects the existing queue policy and never re-enables it.

POST /v1/notifications with an Idempotency-Key (persist and reuse the exact key/body after an uncertain result):

{"channel":"RCS","recipient":{"testRecipient":"test:customer-001"},"templateId":"order.rcs.v1","locale":"en","parameters":{"order":"123"},"expiresAt":"2026-10-28T12:00:00Z","clientReference":"order-123-ready"}

Use a future UTC expiry, at most 24 hours ahead. E.164 numbers, URLs, usernames, LIVE and real provider bindings are refused. Service messages traverse the durable queue and the dedicated network-free RCS adapter. Read GET /v1/notifications/{id}; ACCEPTED is provider simulation acceptance, not DELIVERED.

API: OTP

POST /v1/verify/verifications with verify:write and a UUID Idempotency-Key:

{"channel":"RCS","recipient":"test:customer-001","purpose":"signup"}

GET /v1/verify/verifications/{id}/test-code requires the separate verify:test-code:read permission. POST /v1/verify/verifications/{id}/checks accepts {"code":"<six digits>"}; use distinct persisted UUID keys for create/check/resend/cancel. The normal response and journal never return the code. Resend and cancel use their respective endpoints. OTP is simulated by the same pure FAKE adapter inside the existing atomic Verify admission; it does not dispatch through the notification queue. A future network adapter must execute outside SQL transactions with a durable, reconciled attempt model.

Limits: five-minute TTL, five failed checks, two resends, 30-second resend and same-recipient/purpose cooldown. Project creates: 100/hour; recipient creates: five/hour, shared across Verify channels so channel changes cannot bypass abuse limits. Verify requests: 600/minute; FAKE inbox reads: 60/minute. At most 1,000 stored challenges per project in this staging lab. Cabinet service sends: 100/hour per organization. API requests, queue capacity and project budgets add independent limits. No automatic fallback to SMS, Telegram or WhatsApp exists.

TEST billing and budgets

Sample standard platform fee: USD 0.01 per accepted service notification, USD 0.05 per unique successful verification. These are TEST sample platform prices; provider cost is zero for FAKE, with no assertion about Google's or carriers' future prices. The same wallet and UTC daily/monthly project budgets reserve before admission. Notifications settle at acceptance; definitive failure/expiry releases the hold. Unknown delivery retains its hold for reconciliation. OTP settles only on successful code verification; cancellation, expiry or exhausted checks releases its hold. Failed checks and resends do not add another success fee. Idempotent replay cannot duplicate a reservation or settlement.

Affiliated projects inherit zero platform fees. The operator can enable RCS notification fees with the RCS feature override and OTP fees with VERIFY, independently. Accepted prices remain immutable when affiliation or policy later changes. A fee override never activates a real channel or payment. A zero or already exhausted budget blocks all new admissions, including waived ones. Otherwise a zero-price waived admission consumes no money budget and still obeys rate/capacity limits.

SDK and release boundary

The JVM SDK source adds CreateRcsNotification, CreateRcsNotificationRecipient and HailMeClient.createRcs. This source addition is not publication of a new Maven version; the previously published SDK remains unchanged. Use HTTP for Verify. Keep service keys on the backend; mobile clients must not contain them. Production uses platform.hailme.app; local TEST uses https://localhost:8444 with the local certificate trusted explicitly.

Google protocol preparation with mocks

The source now includes a separate GoogleRcsTransport for scoped capability checks, AUTHENTICATION/TRANSACTION text sends and revocation, plus signed webhook parsing and a reusable inactive receiver. The packaged stage-only protocol rehearsal uses an in-process MockEngine with synthetic tokens and opens no real provider sockets or database connections. The real transport is not selected by the cabinet/API FAKE composition, and the public Google webhook route is not registered. No Google credential, provider approval, real delivery, tariff or LIVE activation is implied. Details and remaining durable-worker/storage gates: Google RCS transport.

Before enabling real RCS

• Receive actual Google approval and console access, confirm operator, brand, target countries and carrier reachability. Application submission is not approval.
• Provision and launch appropriate agents for authentication and transactional traffic; validate the permitted use case for each. Never infer reachability from a country code or consumer RCS support.
• The protocol adapter and receiver have mock tests. Still wire encrypted credentials, durable inbox/outbox and dispatch worker, consent/abuse policy, reconciliation and delivery receipts, then validate them against Google. FAKE does not attest real-provider behavior.
• Obtain country/carrier pricing and publish a reviewed commercial tariff separately from the sample wallet prices.
• Add explicit scoped live gates, finite own-recipient controls, monitoring, backup and rollback. Rehearse on staging before a separately bounded own-HailMe production integration.
• This package adds no DDL migration: existing VARCHAR channel fields and Verify tables are reused. Production remains unchanged. A future rollback after RCS rows exist must understand RCS enum values; the pre-RCS binary is not a supported automatic rollback for those rows.

References: Google agent use cases, capability checks, sending messages.