Skip to main content

Notifications QA Checklist

Prerequisites

  • Local QA smoke passes.
  • Notification/email/SMS capture sink passes ./scripts/local-validation/qa.sh test notifications.
  • Real provider runs have approved sandbox sender identities, recipient inboxes or phone numbers, suppression-list state, provider console access, template IDs, webhook/signature secrets, and opt-in proof recorded before sending.

Manual Local Checks

  • In-app notification create/list/detail/read/read-all.
  • Notification list/detail/read/read-all states are checked with empty fixture data and populated fixture data.
  • Receipt email capture for eligible POS-originated transaction.
  • Receipt SMS capture for eligible POS-originated transaction.
  • Merchant receipt email/SMS call sites reach the shared notification publisher with customer-safe transactional category, org attribution, populated idempotency key, hosted receipt URL, and no merchant-copy/raw PAN leakage.
  • Return/refund/operator alert capture.
  • Terminal Gateway sync failure publishes only an operator alert to the configured ops recipient, with ops-alert category and a stable operator-alert:gateway-sync:* idempotency key.
  • Idempotency prevents duplicate outbound messages.
  • Template data contains expected org/store/customer/transaction fields.
  • Customer-facing notification is not emitted for Gateway-owned event.
  • Gateway webhook/customer-event call sites do not depend on customer-facing email, SMS, receipt, or notification publishers; verify this separately from the lower-level capture sink forbidden-key query.
  • Run ./scripts/local-validation/qa.sh test notifications and verify the report includes org/store/idempotency filtered capture isolation for receipt and operator alert records, zero receipt/customer captures for the forbidden Gateway-owned payment event key, and zero customer-facing receipt captures for operator invalid-recipient/provider-failure scenarios.
  • Invalid recipient and provider failure are surfaced correctly.

Manual Staging Checks

  • Verify SendGrid template/config, suppression-list behavior, and test inbox delivery.
  • Verify SMS provider/carrier delivery with approved test numbers.
  • Verify production-like receipt links only with staging-safe data.
  • Verify email sandbox/provider callback paths: accepted, delivered, bounced, suppressed, invalid recipient, duplicate idempotency key, unsubscribe/opt-out, and provider webhook replay all update local/staging state as expected.
  • Verify SMS sandbox/provider paths: delivered, failed, carrier delay, opt-out, invalid number, duplicate send, status callback replay, and no-send for Gateway-owned events.
  • Verify OAuth/provider emails or SMS used during integrations are captured as provider-owned artifacts and do not create POS customer-facing receipt messages unless the flow explicitly requests one.

Expected Evidence

  • Captured message IDs/payloads.
  • .dev-logs/qa/reports/notification-capture-* report path.
  • Staging email/SMS screenshots or provider logs.
  • Explicit no-notification evidence for forbidden Gateway-originated cases.
  • Org/store/idempotency-filtered capture evidence for positive and forbidden customer-facing notification keys.
  • Provider artifact fields: provider, sandbox/account, template ID, recipient alias, opt-in state, message ID, webhook/status event ID, transaction/receipt ID, negative case, delivery result, screenshot/provider-log path, tester, and timestamp.