Test Strategy and Acceptance Checklist

Use this chapter to move from a working development example to a production-ready partner service. Test the complete user and server lifecycle, not only link generation.

Test with a card programme in Testing Mode and with non-production data. Use at least one supported physical Samsung device for end-to-end acceptance; browser-only token or schema checks do not prove that the card renders or behaves correctly in Samsung Wallet.

Minimum acceptance coverage

Area	Verify
Card data	Required common and card-type fields are present; timestamps, localisation, images and structured strings use the documented formats.
Security	Tokens have the correct headers, algorithms, identifiers and validity period; altered, expired and replayed requests fail safely.
Add flow	The selected link opens on each supported channel, displays the expected card and completes only once for repeated user actions.
Callback flow	The partner receives and correlates card-state events, authenticates requests and handles duplicates idempotently.
Lifecycle	Updates, cancellations, expiry and user deletion produce the expected partner and device state.
Availability	Unsupported devices, regions and service states receive an appropriate fallback rather than a broken ATW journey.
Operations	Secrets are not logged; request IDs are traceable; retry, timeout and incident procedures are documented.

Evidence to retain

Retain the test card programme and template identifiers, test cases and results, representative request IDs, screenshots of the rendered card, callback evidence and the approved exception record for any untested conditional capability. Do not retain real user card data in test evidence.

Use the Online Test Tool for early validation and the Code Lab for a guided exercise. Neither replaces partner-specific lifecycle and production-readiness testing.