Launch Checklist
Complete this checklist after a working UAT integration. Platform approval, production merchant configuration, and payment/settlement verification are separate gates.
Merchant and Configuration
- Production account access and processor configuration assigned.
- Merchant name, tax ID, MCC, and US address validated.
- Terminal uses the processor's live credentials, preserving leading zeros.
- Location belongs to the intended merchant and links the correct terminal.
- Production SDK client key and merchant login credentials supplied through trusted channels.
- Privileged backend API keys remain on the server, with the required permissions.
See Account Hierarchy, Merchant Setup via API, and Terminal/Location Routing.
App and Platform
| iOS | Android |
|---|---|
| Released SDK installed through SPM/CocoaPods or the released XCFramework. | Released SDK resolved from Maven Central or the supplied release AAR. |
| Bundle ID, approved Tap to Pay capability, and signing profile agree. | Signed, non-debuggable release build with minification verified. |
| Explicit merchant account-linking action, reader preparation, and readiness implemented. | KiC package visibility, kernel installation, NFC lifecycle, enrollment, and readiness implemented. |
| Publishing/distribution approvals completed for the selected distribution path. | Developer options disabled for enrollment and payments; distribution requirements completed. |
Use iOS Production Configuration and App Store Launch, or Android Production Deployment. Apple's Tap to Pay integration steps include entitlement, design, and app review requirements; follow the current platform guidance for your app.
Checkout and Operator Experience
- Active-location selection available in settings and shown on the payment screen.
- Selected location revalidated after login, merchant changes, or routing updates.
- Checkout blocked until location selection and platform readiness succeed.
- Amount and merchant identity shown clearly; payment results and receipts distinguish a hold from a captured sale.
- Partial approval and surcharge decisions handled using returned transaction data.
- Decline, cancellation, missing response, and pending states handled without falsely showing success.
- Supported accessibility and merchant education flows tested for the app's distribution path.
Use the canonical iOS or Android response-handling implementation.
Recovery, Webhooks, and Settlement
- Operation IDs saved durably before submitting methods that accept them.
- Lost/duplicate responses reconciled through the recovery flow, without blind charge retries.
- Webhook signatures verified over the raw body.
- Deliveries and jobs persisted atomically before acknowledgment; worker failures remain retryable.
- Duplicate and out-of-order events cannot repeat side effects or regress recorded state.
- Processor batch behavior implemented, including the Fiserv managed cycle or supported manual close/release flow.
- Transaction totals reconciled against batch submission and processor reports.
Pilot and Operations
- Controlled live verification agreed with the processor/Koard contact.
- Support owner can investigate with merchant, location, terminal, environment, transaction, and event IDs.
- Logs and support exports exclude credentials and sensitive payment data.
- Monitoring covers payment outcomes, unresolved orders, webhook failures, and settlement discrepancies.
- A pilot group, rollout owner, and way to pause new payment initiation are assigned.
Request integration support through support@koard.com.
