Live Provider Certification Evidence

Live Provider Certification Evidence is the launch checklist for proving that a configured provider account or device works with real credentials, signed callbacks, SquareOS state changes, and owner/support approval before staff rely on it.

What this page is for

Who should use it

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

Where to find it

Provider go-live checklist across Admin, Communications, Commerce, POS Terminal, and Biometric settings

Before you start

Live provider certification evidence gate: every live provider must have proof at the provider, API, Staff app, audit, and owner/sign-off layers before the gym treats the provider as production-ready.
Provider setup is not production-certified until one successful signed live callback, provider-side reference, SquareOS state change, audit/outbox evidence, and owner/support sign-off are captured for the same tenant.
Razorpay live certification requires a real low-value payment or payment-link payment, x-razorpay-signature verified webhook, matching provider payment id, paid invoice, payment allocation, and audit trail row.
SMS live certification requires fake mode off, one MSG91 or Exotel provider message id, matching POST /engagement/sms/:provider/webhook callback, DeliveryAttempt status update, Message update, and campaign log update when campaign-originated.
Email live certification requires one SES SendEmail provider message id plus SNS Delivery/Bounce/Complaint callback, or one SMTP provider message id plus certified adapter callback, before invoice email is called certified.
WhatsApp live certification requires Meta template send to an opted-in test phone, signed status callback, message delivery/read update, and inbound reply visible in Inbox and profile activity.
Facebook Leads live certification requires Meta lead testing tool or real test form submission, verified x-hub-signature-256 webhook, Graph API lead fetch, duplicate-safe person, opportunity, task, facebookLeadEvent, and crm.facebook_lead.created.v1 outbox event.
POS terminal live certification requires a real Razorpay POS, Paytm POS, or Pine Labs terminal handoff, verified terminal webhook or certified adapter callback, one state transition on the matching SquareOS payment, and settlement/reconciliation evidence.
Access hardware live certification requires a Matrix COSEC, ZKTeco, or Suprema command round trip, idempotent retry proof when retries are enabled, signed/tokenized access event ingestion, denied-event mapping, and access-event-to-check-in bridge proof.
Provider certification evidence must record environment, tenant, provider account or device id, staff test account, timestamp, provider reference, webhook event id, SquareOS record ids, status before and after, screenshots/log links, and approver.
Provider certification failure must leave the staff action disabled or marked accepted limitation; never train staff to bypass provider readiness with manual provider references.
Provider certification evidence template: create one evidence row for each provider account, sender, Page/form, terminal, or access device before launch.
Evidence row fields are Certification ID, Provider family, Provider name, Tenant host, Gym/location, Provider account or device ID, Staff test account, Live action, Provider reference, Webhook event ID, SquareOS record IDs, Before status, After status, Signature/token verification, Outbox/dead-letter evidence, Result, Approver, and Follow-up issue.
Certification result options are Not started, In progress, Passed, Failed, Accepted limitation, and Blocked.
Provider family values are Payment gateway, SMS, Email, WhatsApp, Facebook Leads, POS terminal, and Access hardware.
Live action must name the exact operation tested such as Razorpay payment-link paid, MSG91 SMS delivered, SES bounce callback, Meta WhatsApp inbound reply, Facebook leadgen fetch, Pine Labs terminal success, or ZKTeco denied event.
SquareOS record IDs must include the relevant invoice, payment, delivery attempt, message, campaign log, person, opportunity, task, webhook event, access event, check-in, outbox, or dead-letter ids.
A Passed evidence row requires Signature/token verification = Verified and Result = Passed.
Accepted limitation rows must include owner approval, disabled staff action or visible limitation text, and the follow-up issue if the provider will be revisited.

Daily workflow

Before live testing, confirm the provider account/device is connected in Admin, fake/safe mode is off, the gym owner approved the test, and the test amount/recipient/card/device is low-risk.
Run the provider-specific live action: Razorpay payment, SMS send, SES/SMTP email send, WhatsApp template send plus reply, Facebook lead test, terminal payment, or access-control command/event.
Capture provider evidence first: provider dashboard reference, message id/payment id/terminal transaction id/leadgen id/device command id, provider status, and provider timestamp.
Capture SquareOS evidence next: provider webhook event id, signature/token verification state, updated payment/message/delivery/access/lead/check-in record ids, audit row, outbox/dead-letter state, and before/after status.
Fill the evidence row immediately after the test while provider dashboard and SquareOS records are both open. Do not leave provider reference, webhook event id, or SquareOS record IDs blank for Passed rows.
If the result is good, record owner/support sign-off with the provider account/device id and enable staff actions only for that tenant/location/provider combination.
If the result fails, leave the staff action disabled or mark it as accepted limitation, keep fake/safe mode or provider-disabled reason visible, and create a follow-up issue with provider reference and SquareOS record ids.

Watch out

Do not use simulated provider ids, fake-mode completed commands, test-mode payment events, or manually entered references as live provider certification.
Do not certify one gym, phone number, Page/form, terminal, or access device and assume another location/provider identity is also certified.
Do not expose provider secrets, webhook tokens, API keys, callback signatures, access tokens, or raw credential screenshots in launch evidence. Store only references, masked values, and approved log links.
Do not enable retries for open-gate commands during certification unless the vendor adapter proves idempotency using SquareOS commandRequestId/idempotencyKey.

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