Live Provider Certification Status Register

What this page is for

Live Provider Certification Status Register classifies every provider account, sender, Page/form, terminal, and access device so launch teams can tell the difference between setup guidance and real live proof before staff or mobile users rely on a provider path.

Who should use it

Owners, launch team, support, finance, communications admin, platform admin, mobile implementation team

Where to find it

Provider evidence rows, Admin integration settings, Commerce, Engagement, POS Terminal, Biometric Setting, mobile provider readiness

Before you start

• Live provider certification status register
• Provider certification status register separates Setup documented from Live credential proof pending, Real device proof pending, Accepted limitation, Blocked, and Passed for each provider account or device
• Razorpay gateway status must not be Passed until a live low-value payment or payment-link payment has verified x-razorpay-signature, matching provider payment id, SquareOS invoice/payment/allocation state change, audit row, and finance sign-off
• MSG91 and Exotel SMS status must not be Passed until fake mode is off, real opted-in phone send returns provider message id, POST /engagement/sms/:provider/webhook verifies token or signature, and DeliveryAttempt, Message, and CampaignDeliveryLog update when campaign-originated
• SES and SMTP email status must not be Passed until real recipient send returns SES MessageId or SMTP provider id, signed SNS or certified adapter callback updates delivery state, and bounce/complaint or failure handling is verified without dead-letter
• Meta WhatsApp status must not be Passed until an approved template is sent to an opted-in test phone, signed Meta status callback updates delivery/read state, inbound reply appears in Inbox/profile activity, and template variables match approved order
• Facebook Leads status must not be Passed until Meta Lead Ads Testing Tool or real form submission sends verified x-hub-signature-256 webhook, Graph API fetch succeeds, duplicate-safe person/opportunity/task are created, facebookLeadEvent is stored, and outbox event is emitted
• POS terminal status must not be Passed until one physical Razorpay POS, Paytm POS, or Pine Labs transaction with fake mode off produces verified callback/token/checksum, matching terminal payment/invoice/allocation transition, receipt/provider log, settlement or batch evidence, and finance sign-off
• Access hardware status must not be Passed until one Matrix COSEC, ZKTeco, or Suprema live command round trip, idempotency proof when retries are enabled, signed/tokenized access event, denied-event mapping, and access-event-to-check-in bridge proof are recorded
• If live credentials or hardware are unavailable, provider certification status must be Blocked or Accepted limitation with disabled staff action, owner approval, follow-up issue, masked evidence row, and no mobile or Staff app bypass path

Daily workflow

• Create one status row for each live provider identity, not just each provider family. A gym can have multiple Razorpay accounts, SMS senders, WhatsApp phone numbers, Facebook Page/form mappings, POS terminals, or access devices, and each one needs its own status.
• Use Setup documented only when the SquareOS setup page, required fields, callback path, readiness state, and troubleshooting guide exist, but the tenant has not yet produced real provider evidence.
• Use Live credential proof pending when credentials are expected but the real Razorpay, MSG91, Exotel, SES, SMTP, Meta WhatsApp, or Facebook Leads credential test has not completed for that tenant/provider identity.
• Use Real device proof pending when a physical terminal or access device is configured in docs/admin but the actual Razorpay POS, Paytm POS, Pine Labs, Matrix COSEC, ZKTeco, or Suprema device has not produced live callback/command evidence.
• Use Passed only after the provider-specific proof in this register and the Live Provider Certification Evidence page both exist for the same tenant, provider account/device, environment, and staff test action.
• Use Failed when the live test ran but signature verification, provider reference matching, SquareOS state change, outbox/dead-letter state, or owner sign-off did not meet the pass rule. Keep staff actions disabled until the failure is resolved or accepted.
• Use Accepted limitation only with owner approval, visible disabled/limitation copy, masked evidence row, follow-up issue, and a clear statement that staff and mobile users cannot bypass the missing proof.
• Use Blocked when credentials, provider portal access, vendor onboarding, hardware, callback forwarding, DNS, Page/form permission, adapter support, or owner approval is missing and launch cannot honestly certify that path.
• For mobile readiness, expose only the certification status, provider family/name, tenant/location, masked account/device label, last verified time, disabled reason, certification id, follow-up issue, and Staff app deep link. Never expose the evidence payload itself.

Watch out

• Do not mark Passed because a fake-mode flow, test-mode provider event, dashboard screenshot, or manually typed provider reference looks successful.
• Do not reuse certification from another tenant, gym location, phone number, Page/form, sender, terminal, access device, or environment.
• Do not let Staff app or mobile turn Accepted limitation into a hidden success path. The limitation must stay visible and the risky action must stay disabled or explicitly owner-approved.
• Do not put live secrets, webhook signatures, callback payloads, terminal receipts with private payment data, biometric/card identifiers, or provider portal screenshots with credentials into this public documentation site.

Related help

• Use the left menu to open related pages in Start Here.
• Use Ask Docs for questions that are already covered in this public documentation.