CustomerNode™

Theme: Light
Financial Services › Financial Services & Banking › Payments & Card Networks

Issuer Processing

Regulated environments where trust, compliance, and operational resilience are non-negotiable.

Example organizations in this space: Fiserv FIS TSYS i2c

This interactive experience is the shipped product itself — the same application code customers run in production, mounted read-only in your browser over a real sample journey. Not a video, not a mockup: because the demo and the product are one codebase, it can never drift from the real thing.

Inside this journey

  1. Pre-Sales

    Qualify and diagnose before investing in a full evaluation cycle.

    1. Qualification

      Confirm budget, decision process, technical constraints, and timeline before investing in a full evaluation cycle.

      Qualification Questions

      Operational fit, migration scope, and technical constraints

      • To help us use your time well, roughly how many authorization transactions do you process per month? Options: Under 100,000, 100,000–1,000,000, 1,000,000–10,000,000, 10,000,000–100,000,000, More than 100,000,000
      • Are you planning to migrate active cardholder accounts as part of this project, and if so, about how many accounts? Options: No migration, greenfield, Under 50,000, 50,000–500,000, 500,000–2,000,000, 2,000,000–10,000,000, More than 10,000,000 (requires special handling)
      • Do you have regulatory or data residency requirements that will affect where cardholder or transaction data may be processed or stored? Options: No, Yes — data must remain in country of issuance (will provide details), Yes — specific certifications required (PCI, SOC, other), Unsure, need to confirm

      Product fit and configuration needs

      • Will you need custom processing features or integrations beyond standard issuer functions (for example custom rewards, billing rules, or third-party connectors)? Options: Mostly standard configuration, Minor configuration only, Moderate custom development, Significant custom development required, Unsure, will clarify in discovery

      Budget

      • Is there an allocated budget range for a platform selection or migration project? Options: Yes — under $250k, Yes — $250k to $1M, Yes — $1M to $5M, Yes — over $5M, No budget yet / under discussion

      Decision process and timeline

      • Who is the primary decision owner for selecting a processor, and which roles should be included in the technical evaluation? Options: Head of Cards / Product, CTO / VP Engineering, CFO / Finance, Head of Operations, Legal / Procurement, Implementation partner / Systems integrator, Other (please specify)
      • What is your target timeframe to reach a go-live decision or to start migration? Options: Immediate (0–3 months), Short (3–6 months), Medium (6–12 months), Long (12+ months), No set timeframe

    2. Enterprise Discovery

      Map current processing architecture, transaction volumes, reliability targets, stakeholder roles, and measurable success criteria.

      Discovery Questions

      Where your card program stands today

      • Tell me about your current card products and the number of active accounts in each product line.
      • Estimate your typical monthly authorization volume and the peak transactions per second you must handle. Options: < 10k / month, 10k–100k / month, 100k–1M / month, 1M–10M / month, > 10M / month
      • On average, what authorization availability do you report today in basis points of downtime risk (examples: 5 bps, 20 bps)? Options: < 5 bps, 5–20 bps, 21–50 bps, > 50 bps, We do not track bps
      • Which card features are critical for your roadmap in the next 12 months, for example dynamic controls, installment products, or complex rewards tiers? Options: Real-time controls, Custom rewards, Installments/splits, BIN-level routing, Tokenization/Wallets, Other
      • If you had to prioritize one program goal for the next 12 months, which would it be: reliability, faster product launches, lower operating cost, or regulatory readiness? Options: Reliability/uptime, Faster product launches, Lower operating cost, Regulatory/compliance readiness, Other
      • If a sustained 100 basis point drop in authorization availability occurred for a week, what immediate business consequence would you expect?

      Where the current setup frustrates your team

      • What single operational failure during a platform migration would make you halt the project immediately? Options: Mass customer card declines, Data loss or reconciliation gaps, Regulatory noncompliance, Third-party integration failure, Other
      • Walk me through the last time your processor experienced an authorization outage, including duration, root cause, and number of affected cardholders.
      • Who inside your organization must lead incident response during processing interruptions and how quickly can they be staffed outside business hours? Options: Operations, Payments engineering, Issuer product, Risk/fraud, Third-party ops
      • How many active cardholders, by product type, would require conversion in a phased migration versus a bulk conversion? Options: < 100k, 100k–500k, 500k–2M, 2M–10M, > 10M
      • Do you have an established rollback plan for migrations that includes customer communications and reversible data steps? Options: Yes, fully documented, Partial plan exists, No formal plan, We rely on vendor plan
      • If your legal or compliance team required additional escrowed controls that add 4 weeks to the schedule, would the program timeline be postponed or re-scoped? Options: Postpone timeline, Re-scope migration, Proceed with mitigations, Decision pending

      The costs you may not be counting

      • To what extent does your current processor force trade-offs between releasing new features and maintaining authorization stability? Options: Always trade-off features, Occasionally, Rarely, No trade-off
      • Which internal teams would need to be dedicated to a migration for an 8–12 week window (select all that apply)? Options: Engineering, Operations, Fraud/Risk, Legal/Compliance, Customer Service, Product
      • Estimate the internal FTE-weeks and external vendor spend you expect for a parallel processing pilot across one product line. Options: < 50 FTE-weeks / <$100k, 50–150 FTE-weeks / $100k–$500k, 150–400 FTE-weeks / $500k–$2M, > 400 FTE-weeks / >$2M
      • Describe the most time-consuming manual process your operations team performs during settlement or dispute handling and the frequency of that work.
      • Would you cancel or pause the project if projected migration costs exceeded your internal budget by 20%? Options: Cancel, Pause and re-scope, Seek additional budget, Proceed regardless

      Who else you are actually considering

      • Why are you continuing conversations with the incumbent rather than moving forward today? Options: Better pricing, Familiarity and risk aversion, Contractual lock-in, Feature gaps with alternatives, Other
      • List the alternatives you are actively evaluating today, including internal rebuild efforts, and indicate the evaluation stage for each. Options: Incumbent processor, Internal rebuild, Other third-party processor, Processor marketplace/platform, Not sure/early stage
      • What conditions about your current platform would need to be true for you to decide to stay rather than change providers?
      • Has anyone inside proposed solving processing needs entirely in-house, and if so, which executive sponsors back that plan? Options: Yes, strong exec backing, Yes, exploratory only, No internal proposal, Don't know
      • Would you remain with the incumbent if they committed to a time-bound migration support package guaranteeing no customer interruptions? Options: Yes, No, Maybe, need details, Depends on commercial terms

      Integration and data readiness, the practical gate checks

      • Identify any core systems that cannot expose the APIs we require within an 8-week integration window.
      • Who owns the primary integration endpoints for authorizations, disputes, and settlements and are those teams available for weekly sprint work? Options: Internal payments engineering, Third-party integrator, Shared cloud team, Not assigned
      • Provide your current data match rate for account identifiers during transfers and name the team responsible for data remediation. Options: > 99%, 95–99%, 85–95%, < 85%, Unknown
      • Do you have outstanding regulatory approvals, contracts, or data residency constraints that will block account export or token migration? Options: Yes, approvals pending, Yes, contractual constraints, No blockers, Unsure
      • Select third-party systems that must integrate for a full migration (select all that apply). Options: Fraud scoring vendor, Loyalty/rewards platform, Billing/statement engine, Card network routing/BIN sponsor, Wallet/tokenization provider, Customer support platform
      • How would you respond if a critical integration owner could not commit resources during the planned migration window, postpone, re-scope, or assign alternate owners? Options: Postpone, Re-scope, Assign alternates, Cancel migration

      How you will judge success and accept the change

      • Assuming a pilot demonstrates the expected reliability and performance targets, what internal obstacle would still prevent you from signing within 30 days? Options: Legal terms, Budget approval, Board sign-off, Operational readiness, Other
      • List the stakeholders required to sign off on SLA acceptance, billing changes, and final go-live and note their typical review cycle. Options: Executive sponsor, CFO/finance, Legal/compliance, Head of cards, Operations, Risk
      • Name the primary metrics you will use to accept the platform, and provide target values where possible (examples: authorization availability in bps, reconciliation lag in hours).
      • Select the team that will own runbook approvals and nightly incident triage during cutover. Options: Operations, Payments engineering, Third-party ops, Shared on-call
      • Can procurement sign a commercial term that defers some non-critical legal items to post-go-live if technical and operational targets are met? Options: Yes, Maybe with exceptions, No

      If we clear these, how quickly can we move

      • When can your team realistically begin a full-time 8-week migration window with core resources allocated? Options: Immediately (within 2 weeks), Within 4–6 weeks, Within 7–12 weeks, No date available
      • Choose your preferred resourcing model for migration execution. Options: Mostly your internal team, Shared responsibilities with vendor, Vendor-led with internal oversight, Third-party systems integrator-led
      • Name the single internal milestone that, if cleared this month, would allow you to sign within 30 days.
      • Do you have a target budget range for the first year of operations post-migration? Options: < $250k, $250k–$1M, $1M–$5M, > $5M, Budget not set
      • Can your board approve a time-bound commercial term that guarantees migration milestones if finance confirms runway? Options: Yes, board-ready, Needs board discussion, No, cannot approve

  2. Solution Evaluation

    Validate platform reliability, APIs, and migration approaches against buyer acceptance criteria using parallel testing and defined metrics.

    • desired_state
    • current_state
    • stakeholders
    • gaps
    • success_criteria
    • decision_readiness
    • desired_state
    • decision_readiness
    • current_state
    • success_criteria
    • gaps
    • stakeholders
    • desired_state
    • success_criteria
    • stakeholders
    • gaps
    • current_state
    • decision_readiness
    • decision_readiness
    • decision_readiness
    • decision_readiness
    • decision_readiness

  3. Solution Scope

    Define modules, migration approach (phased or parallel), responsibilities, SLAs, and measurable acceptance criteria.

    Scope Configuration

    • Provision Issuer Processing Environment
    • Onboard BINs and Network Routing
    • Migrate Cardholder Accounts (Phased Conversion)
    • Parallel Processing and Transaction Reconciliation
    • Card Tokenization and PAN Vaulting
    • Real-time Authorization Rules Implementation
    • Fraud Scoring and Risk Rule Deployment
    • Rewards Program Configuration and Integration
    • Cardholder Account Management Enablement
    • Statement Generation and Billing Cycle Setup
    • Dispute and Chargeback Workflow Configuration
    • PIN Management and Card Activation Services
    • Card Production and Fulfillment Integration
    • Settlement, Funding and Network File Integration
    • Compliance Reporting and Regulatory Export Setup

    Scope Questions

    Provision Issuer Processing Environment

    • What peak transactions per second (TPS) and daily transaction volume must the processing environment support, and please list typical burst factors? Options: Less than 100 TPS / <100k daily, 100-1,000 TPS / 100k-1M daily, 1,000-5,000 TPS / 1M-5M daily, More than 5,000 TPS / >5M daily
    • Which ISO 8583 or ISO 20022 message versions and custom field sets does your current authorization switch emit that we must accept?
    • How should we provision environments for development, test, pre-production and production including expected data residency and PCI DSS segmented scope? Options: Standard dev/test/preprod/prod in same region, Separate regions for prod/data residency required, We require isolated PCI DSS scoped vaults, Describe a specific topology
    • Who will own platform-level access and the list of administrator accounts for the first 90 days after cutover?
    • Are there failover and RTO/RPO targets for the environment (recovery time objective and recovery point objective) we must meet? Options: RTO<15 minutes, RPO<1 minute, RTO<1 hour, RPO<5 minutes, RTO<4 hours, RPO<15 minutes, Custom targets - describe

    Onboard BINs and Network Routing

    • How many BIN ranges need onboarding and what are the numeric ranges for each BIN block to be configured?
    • Which card network routing rules and fallback priorities must be configured in the switch routing table (for example primary route, secondary route, emergency route)? Options: Single primary route, Primary plus single fallback, Primary, secondary, emergency, Custom routing matrix - describe
    • What merchant category code (MCC) or acquirer mapping exceptions exist that will require custom BIN-to-MID routing? Options: No exceptions, MCC-based exceptions exist, Acquirer-specific mapping required, Provide list of exceptions
    • Are there test cards and simulation endpoints you will provide for network certification and BIN acceptance testing? Options: Yes, full test card set, Partial test artifacts, No, need provider test harness, Describe available artifacts
    • Who is the owner for BIN registration and network connectivity approvals and what are their required legal/contract documents for network enrollment?

    Migrate Cardholder Accounts (Phased Conversion)

    • How many active cardholder accounts and cards are in scope for the phased conversion and how will you group them into batches? Options: Less than 10k, 10k-100k, 100k-1M, More than 1M
    • Which account data elements must be migrated intact (PAN token, primary account number last4, card product code, statement cycle, billing address, reward balances, dispute history)?
    • What cutover window and daily conversion throughput do you require for each migration batch to limit cardholder impact? Options: Nightly 2-hour window, Weekend 24-hour window, Rolling nightly windows, Custom schedule - describe
    • What reconciliation accuracy threshold must be met between source and target for a batch to be approved (for example account balance parity, transaction history match rate)? Options: 99.5% parity, 99.9% parity, 99.99% parity, Custom threshold - describe
    • What defines done for a phased conversion batch including migration completeness, authorization parity, and customer communications confirmation?

    Parallel Processing and Transaction Reconciliation

    • Which transaction classes (authorizations, captures, reversals, refunds) must run in parallel against source and target during validation? Options: Authorizations only, Authorizations and reversals, All transaction classes including captures and refunds, Custom selection - describe
    • How long should parallel run-in last per account cohort and what sample size or percentage of live traffic do you want mirrored? Options: 7 days / 10% sample, 14 days / 25% sample, 30 days / 100% for cohort, Custom duration/sample - describe
    • Which reconciliation artifacts do you require (ISO 8583 journal comparisons, switch logs, network receipt files, settlement trace reports) for parity checks? Options: ISO 8583 journals, Network receipt files, Switch logs + trace reports, All of the above
    • What tolerance for transaction-level divergence is acceptable during parallel processing (for example acceptable mismatch rate and allowable authorization response differences)? Options: 0.01% mismatch, 0.1% mismatch, 0.5% mismatch, Custom tolerance - describe
    • What acceptance criteria will validate successful parallel processing reconciliation including metrics and required evidence?

    Card Tokenization and PAN Vaulting

    • Which tokenization scheme do you require (network tokenization, platform token with mapping to PAN vault) and must tokens be reusable across merchants? Options: Platform token mapped to PAN vault, Network tokenization required, Hybrid model, Undecided - need guidance
    • What PCI DSS scoped elements must remain on-premise versus in the vault and what key management model do you require (HSM with customer KMS or shared keys)? Options: Provider HSM with shared keys, Provider HSM with customer KMS, Customer on-prem HSM, Undecided - describe needs
    • How many PANs need to be ingested into the vault and are there truncated PANs or legacy masked formats we must reconcile during import? Options: Less than 10k, 10k-100k, 100k-1M, More than 1M
    • Are there token lifecycle rules required such as token rotation, aging, de-tokenization requests, or merchant-specific token scopes? Options: Rotation required, De-tokenization on demand, Merchant-scoped tokens, No special lifecycle rules
    • Who will own PCI evidence and scope reduction activities related to PAN vaulting and what retention period applies to PAN artifacts? Options: We own PCI evidence, Provider assists with evidence, Joint ownership model, Specify retention period

    Real-time Authorization Rules Implementation

    • What authorization latency SLA do you require measured in milliseconds for peak and off-peak windows? Options: <50 ms, <100 ms, <200 ms, Custom target - describe
    • Which ISO 8583 data elements and custom fields must your rules engine inspect for decisions (for example MCC, POS entry mode, EMV cryptogram presence, AVS, CVV)?
    • Do you need dynamic rule sets by product (credit, debit, prepaid) and by BIN range with override priorities? Options: Yes, by product and BIN, Yes, by product only, No, global rule set, Custom - describe
    • Who will own rule change approvals and what is the expected lead time for production rule deployment and rollback capability? Options: We approve changes, Provider proposes and we approve, Automated A/B rule rollout, Describe approval workflow
    • Are there decision thresholds tied to authorization response codes or routing behaviors that must be enforced (for example decline on high amount, escalate on offline EMV failures)? Options: Yes - list thresholds, No, Need help defining thresholds, Other - describe

    Fraud Scoring and Risk Rule Deployment

    • Which fraud signals and data feeds must be ingested by the scoring model (transaction velocity, device fingerprint, BIN risk score, historical dispute flags)?
    • What target false positive and false negative rates do you accept for real-time scoring, and what is the preferred lookback window for behavior models? Options: FP<1% / FN acceptable, FP<0.5%, Custom targets - describe
    • Do you require machine learning models to be explainable with rule fallbacks and human review queues for high-risk declines? Options: Yes, explainable + human review, No, fully automated, Hybrid - describe
    • Which external watchlists or sanction feeds must be checked prior to authorizing (for example government lists, internal fraud lists)? Options: External watchlists required, Internal lists only, No watchlists, Specify lists
    • Who will maintain model training data and the cadence for periodic model retraining and backtesting? Options: We maintain and schedule, Provider maintains with joint governance, Ad-hoc retraining as needed, Custom - describe

    Rewards Program Configuration and Integration

    • What reward earning rules must be supported (points per spend amount, category multipliers, caps, tiered earn rates) and for which card products?
    • How should reward liability be accounted for on the billing cycle and what GL mapping and accrual schedule must be configured?
    • Do you require real-time reward balance updates in authorization responses or post-authorization batch posting? Options: Real-time updates in auth, Post-authorization batch posting, Both options required, Undecided - advise
    • Which third-party loyalty engines or CRM systems must we integrate with and what integration methods are supported (API push, file export)? Options: API push, SFTP file exchange, Webhook callbacks, Other - describe
    • What reversal and refund rules apply to earned rewards when transactions are charged back or refunded and how should points be adjusted? Options: Automatic reversal on chargeback, Manual reconciliation, Hybrid rules - describe

    Cardholder Account Management Enablement

    • Which self-service APIs must be enabled for your cardholders (balance inquiry, transaction history, dispute initiation, PIN change, card controls)? Options: Balance and transactions, Dispute initiation, PIN change and controls, All listed APIs
    • What authentication factors do you require for API access to cardholder data (multi-factor authentication, device binding, token challenge)? Options: MFA required, Device-based binding, Single-factor acceptable, Custom policy - describe
    • Do you want card controls available to cardholders such as merchant category block, spend limits, and geographic controls activated immediately via API? Options: Yes, full controls, Limited controls only, No cardholder controls, Custom - describe
    • How should historical transaction visibility be handled (rolling 12 months, 24 months, full history) in the portal and APIs? Options: 12 months, 24 months, Full history, Custom retention - describe
    • Who will own SLA for API uptime and monitoring for cardholder endpoints and what alerting channels do you prefer? Options: We own SLA, Provider owns SLA, Joint SLA, Specify alert channels

    Statement Generation and Billing Cycle Setup

    • What statement cycle configurations do you require (monthly cycle date, grace periods, due date offsets) and per product variations?
    • Which statement artifacts must be produced (PDF, plain text, XML for downstream accounting) and what branding elements must be included? Options: PDF with branding, XML for accounting, Both PDF and XML, Other - describe
    • Do you require localized tax and surcharge messaging for specific jurisdictions on statements and billing notices? Options: Yes, localization required, No, Partial jurisdictions - list
    • What minimum billing tolerance and rounding rules should apply to posted balances, interest calculations and fee assessments? Options: Standard rounding to cents, Truncate fees, Custom tolerance - describe
    • Who will approve final statement templates and what is the sign-off process for regulatory text such as consumer disclosures?

    Dispute and Chargeback Workflow Configuration

    • Which chargeback reason codes and representment timelines must be supported and mapped to your dispute SLA matrix?
    • What evidence package format do you require for representments (PDF attachments, structured JSON evidence, or file store links)? Options: PDF package, Structured JSON, File store links, Combination - describe
    • Do you require automated dispute triage rules that route cases to specific teams based on reason code, transaction value, or merchant category? Options: Yes, automated triage, No, manual routing, Hybrid - describe
    • What retention period and audit trail detail must be preserved for dispute workflows to satisfy regulators and audit requirements? Options: 3 years, 6 years, Custom retention - describe
    • Who is responsible for escalation to legal or collections and what notification cadence do you expect for critical dispute cases?

    PIN Management and Card Activation Services

    • Which PIN delivery and activation channels must be supported (IVR, SMS, in-branch, instant issuance kiosk) and what PIN derivation method do you require? Options: IVR + SMS, Instant issuance kiosk, Branch pickup, Multiple channels - describe
    • Do you require offline PIN verification support for ATMs and POS that use offline EMV PIN verification and the necessary PIN verification value (PVV) method? Options: Yes offline PIN required, No offline PIN, Partial offline support
    • What activation workflow must be implemented for new cards (call center activation, in-app activation, first-use activation) and what fraud checks must run at activation? Options: In-app activation + 2FA, Call center activation, First-use activation only, Custom workflow - describe
    • What PIN block formats and encryption profiles must we support for interchange and host-to-host PIN translation? Options: ANSI X9.8 PIN block, ISO 9564 PIN block format 0, Multiple formats - describe, Undecided
    • Who will own PIN change requests and what SLA on PIN change completion is acceptable? Options: We own and SLA 24 hrs, Provider owns SLA <2 hrs, Joint ownership - describe

  4. Mutual Commit

    Finalize commercial and legal terms, SLA commitments, migration milestones, and governance required to proceed.

    Agreement Modules

    • Master Services Agreement (MSA)
    • Statement of Work (SOW)
    • Order Form / Subscription Agreement
    • Service Level Agreement (SLA)
    • Migration Milestone Schedule and Cutover Acceptance
    • Governance and Change Control Agreement
    • Data Processing Agreement (DPA) and Regulatory Addendum

  5. Deployment

    Operationalize rollout with readiness checks, execution, and outcome validation.

    1. Pre-Deployment Readiness

      Confirm owners, environments, access, schedules, and stakeholder communications the deployment depends on.

      Pre-Deployment Questions

      Environment and site access

      • Before we lock a cutover date, is the buyer's production environment provisioned and accessible to the seller's deployment team? Options: Yes — accessible now, Yes — accessible on a scheduled date, No — provisioning required, Not applicable (no production cutover)
      • If the production environment is scheduled or not yet provisioned, what date will it be available? (so we can plan the cutover window)
      • Are the required non-production environments (staging, UAT, sandbox) provisioned and accessible to the seller's deployment team for pre-cutover testing? Options: All non-production environments accessible, Some accessible — limited scope, None accessible, Not required

      Data and configuration readiness

      • Which data domains will be included in the migration or cutover? (select all that apply) Options: Cardholder account records, Active card accounts and balances, Pending/authorized transactions, Transaction history (subset), Rewards and loyalty balances, Product/configuration rules and pricing
      • Has the authoritative source of truth (system and owner) been named and accepted for each domain above? Options: Yes — owners named for all domains, Partial — some domains missing owner, No — owners not defined yet
      • Has the field-mapping and transformation approach been decided and an owner assigned (so mapping work can start without delay)? Options: Yes — approach decided and owner named, Approach decided — owner to be assigned, Approach undecided

      People and ownership

      • Provide the named owner (name and role) for each deployment workstream: technical lead, data migration lead, integration lead, operations/cutover lead, and post-go-live support lead. (these names will drive approvals and runbook accountability)
      • Has the buyer shared a primary and backup escalation/on-call contact for the cutover window? Options: Yes — primary and backup named, Yes — primary only, No — escalation contacts not provided, Seller will provide on-call until buyer names contacts

      Timing, constraints, and approvals

      • Are there known blackout windows, business processing exclusions, or regulatory freeze periods that would prevent cutover? (we need this to avoid scheduling conflicts) Options: No blackout windows, Yes — recurring/regular blackout windows, Yes — fixed date ranges, Unknown / need to confirm
      • If yes to blackout windows or if regulatory/compliance gates apply, briefly summarize the constraint and provide the agreed target cutover date or window (so we can lock resources and approvals).

    2. Configuration Details

      Capture exact integration endpoints, API credentials, data mappings, monitoring thresholds, and cutover windows for execution.

      Configuration Details

      Environments & Endpoints — tell us the exact URLs the platform will call and receive from

      • Production API base URL (format: https://api.your-domain.com). This exact value will be written into the production connector settings. Default: none — enter the full HTTPS URL.
      • Authorization / webhook listener URL (format: https://your-webhook-endpoint.example.com/path). This is the endpoint the platform will POST authorizations/events to. Enter the full HTTPS URL.

      Authentication & credential identifiers — pick the method and provide the non-secret identifier we will reference

      • Authentication method for API calls (select one). This drives which connector the deployment will enable. Options: Mutual TLS (mTLS), OAuth 2.0 (client_credentials), API key (header), Basic auth, None — no authentication
      • Non-secret credential identifier (example: OAuth client_id or integration user name). Enter identifier only — DO NOT paste secrets or tokens. Note: the secret itself will be exchanged via your secrets manager at kickoff.

      Data mappings & reference files — exact field names or file locations the build will load verbatim

      • Source field name that maps to the platform's Cardholder ID (example: customer.account_id). Enter the exact field name used by your source system.
      • Location of code-table / mapping file for status/currency/product codes (format: https://... or s3://bucket/path). If no file, enter 'none'. This path will be fetched during deployment.

      Monitoring, alerts & thresholds — values the runbooks use to trigger notifications

      • Authorization availability SLA threshold (%) — Default 99.95. Enter numeric percent (e.g., 99.95). The deployment monitoring will use this to evaluate go/no-go during cutover.
      • Primary alert channels to notify on threshold breaches (select all that apply). Provide exact channel identifiers later (e.g., Slack channel name, PagerDuty service key owner) at kickoff. Options: Email distribution list, Slack channel, PagerDuty service, Webhook endpoint, SIEM/Log aggregation, Other

      Cutover timing & rollback trigger — the single-window we will schedule

      • Planned cutover start (UTC) — enter exact start in ISO format (YYYY-MM-DDThh:mmZ). This is the canonical start time the deployment automation will use.

    3. Deployment

      Execute the migration with sequenced tasks, runbooks, monitoring, rollback plans, and clear escalation paths.

    4. Go-Live Validation

      Verify acceptance criteria, transaction routing, authorization availability, and data integrity with named sign-offs before declaring go-live complete.

      Checklist items

      • Obtain written Go‑Live Acceptance from the buyer approver
      • Obtain operational readiness sign-off from the seller deployment lead
      • Verify transaction routing and network pathing
      • Confirm authorization availability meets acceptance threshold
      • Deliver data integrity reconciliation report for migrated accounts
      • Validate fraud/risk rule behavior with signed test results
      • Confirm settlement and clearing end‑to‑end tests completed
      • Verify rollback point and execute rollback dry‑run
      • Confirm incident escalation contacts and communication channels
      • Publish go‑live completion declaration signed by buyer and seller sponsors

  6. Success

    Monitor SLA performance, track issues and enhancement requests, and maintain a shared channel for continuous improvement.

    Success Reviews

    • Go-live Health Check (weeks 1-4)
    • First Measurement Review (weeks 4-10)
    • 90-Day SLA and Issue Burn-down Review (around day 90)
    • Operational Quarterly Review
    • Annual Success Review

    Issues & Enhancements

    • Publish prioritized enhancement list for the next quarter with acceptance criteria and planned release windows.
    • Publish an updated runbook and alert threshold matrix to the shared channel.
    • Convert approved enhancements into scoped requests with acceptance criteria and delivery windows.
    • Quarterly SLA and performance summary
    • Ensure SLA metrics remain within agreed tolerances and adjust operational plans for anticipated load changes.
    • Confirm the top 3 enhancements for the next quarter and their acceptance criteria.
    • Maintain a current and specific incident and enhancement backlog with owners and dates.
    • Re-confirm agreed success criteria and owners
    • Update capacity plan and maintenance schedule to reflect projected transaction growth.
    • Circulate the quarter's incident and resolution ledger to the shared channel for auditability.
    • Year-to-date SLA performance and trend summary
    • Agree that annual SLA performance and incident trends are understood and document long-term risk mitigations.
    • Confirm which outstanding enhancements will carry over into the next fiscal year and their priority.
    • Validate that the incumbent is fully decommissioned and that data archival posture meets retention and compliance needs.
    • Publish the annual SLA performance report with recommendations for risk mitigations and capacity investments.
    • Convert carryover enhancements into a prioritized roadmap for the next year with acceptance criteria.
    • Archive the year-end incident and change log to the governance repository for audit and compliance review.
    • Confirm the deployment status is green, amber, or red with an agreed short-term stabilization plan.
    • Document the top 5 live blockers with owners and target resolution dates.
    • Agree daily or weekly checkpoint cadence until the environment is stable.
    • Publish go-live health summary and current incident list to the shared channel for visibility.
    • Collect and share logs and traces for any open high-severity incidents to support diagnosis.
    • Schedule the next measurement review within 4 to 8 weeks to evaluate metric trends.
    • Publish the incumbent decommission checklist and remaining archive steps with target completion dates.
    • Present first full metrics package
    • Establish whether authorization availability and latency are trending toward Solution Scope targets and identify gaps to remediate.
    • Confirm migration completeness as a percentage of active cardholder accounts and document remaining steps to finish migration.
    • Verify the incumbent system wind-down status and capture any remaining archival or contract actions required.
    • Produce a metric drill-down packet with raw data, sampling methodology, and anomaly windows.
    • Open prioritized remediation tasks for each metric gap with expected delivery dates.
    • 90-day SLA performance and trend analysis
    • Document SLA performance outcomes and determine whether remediation plans meet the timeline to close gaps against Solution Scope targets.
    • Achieve burn-down commitments for all severity 1 incidents or agree compensating controls and dates for resolution.
    • Agree prioritized list of enhancements to be scheduled into the operational roadmap.
    • Create a time-boxed remediation plan for any SLA shortfalls with milestones and verification steps.
    • Deployment and migration validation
    • Open issues and enhancement backlog review
    • Enhancements delivered versus planned
    • Open incident and defect burn-down
    • Diagnose root causes for any gaps
    • Long-term operational risks and mitigation roadmap
    • Incumbent system wind-down and data archive status
    • Enhancement request triage and prioritization
    • Early adoption signals and usage patterns
    • Operational risk and capacity planning
    • Blockers and open issues triage
    • Confirm monitoring, alert thresholds, and runbook readiness
    • Continuous improvement channel health
    • Continuous improvement channel and governance check
    • Agree corrective actions and timelines
    • Immediate remediation actions and short-term cadence
Explore more templates Use this template
First-Party AI ™

1-2 minutes please — Your AI agent is working

First-Party AI™ can make mistakes. Always check important information.