Financial Services
›
Financial Services & Banking
›
Payments & Card Networks
Merchant Payment Processing
Regulated environments where trust, compliance, and operational resilience are non-negotiable.
Example organizations in this space:
Square (Block)
Stripe
Adyen
Worldpay
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
-
Pre-Sales
Qualify and diagnose merchant fit before full discovery.
-
Qualification
Confirm budget range, decision-makers, timeline, and core payment needs to determine the appropriate engagement path.
Qualification Questions
Core payment needs and operational fit
- Which payment channels do you need supported?
- Roughly how many transactions do you process per month?
- Which payment outcomes are highest priority for you right now?
Budget
- Is there an allocated budget or target pricing approach for payments (if comfortable sharing)?
- If you can, please state the approximate monthly processing budget or target fee range (free response)
Decision-makers and internal owners
- Who will approve the final provider selection, and who else will influence the decision?
- Which internal teams need to be involved in integration and onboarding?
Timeline and next step
- What is your target go-live date or deadline?
- Is there a specific constraint driving that timing (seasonal peak, funding, contract expiry, etc.)?
- Based on these details, are you ready to schedule a focused discovery meeting to align scope and technical next steps?
-
Merchant Discovery
Map current payment flows, volumes, channel mix, fraud exposure, and stakeholder priorities to define success signals.
Discovery Questions
Starting Point: Your Payments at a Glance
- Tell me about your current payment acceptance footprint, including the channels you sell in and the main ways customers pay.
- Describe a recent month of processing in either transaction count or gross volume so we have a concrete baseline to work from.
- Walk me through a recent large payment day, from checkout through settlement, naming the systems a transaction touches.
- Who owns payments decisions in your organization and which roles must sign off on changing routing, pricing, or providers?
- Which payment methods currently drive the majority of your revenue by volume or value?
- Will inability to support your primary currency and settlement requirements cause you to change providers within 60 days?
Map of Your Money Flows
- If you had to pick one place where your checkout, authorization, or settlement process silently loses revenue, where would you point first?
- In a typical month, how many chargebacks and disputes do you receive?
- Who on your team reviews fraud alerts and makes manual decisions, and how long does a typical manual review take?
- Which routing rules or processor priorities do you already apply, for example by card brand, country, or ticket size?
- When you compare authorization rates across markets or processors, where is the biggest gap relative to your target?
- If authorization optimization could lift approvals by 1% and reduce chargebacks by 10%, how likely would you be to change routing this quarter?
Where It Breaks and How It Affects Your Team
- Describe the last time a payment flow outage or settlement error caused revenue loss or required a manual workaround, and how long it took to resolve.
- Are there repeat failures you can point to, such as specific card brands, gateway timeouts, or reconciliation mismatches?
- Give an example of a recurring customer complaint about the payment experience and how that complaint translates into churn or support cost.
- By roughly how much do failed authorizations, refunds, and manual settlement adjustments add to your monthly operational cost?
- Identify the single SLA or reporting failure that would make leadership classify this project as critical and demand immediate remediation.
Alternatives You're Weighing, and What Would Keep You Where You Are
- Name the categories of solutions you are actively comparing for payments and routing, including any plans to build internally.
- Why would your team decide to keep the current solution instead of switching, in plain measurable terms?
- Rank the evaluation criteria by priority, for example approval rate, fees, settlement speed, integration effort, or fraud controls.
- Have internal stakeholders proposed solving this problem without an outside vendor, and if so, which groups are pushing for an in-house build?
- Would matching incumbent pricing but delivering no improvement in authorization rates be sufficient for you to stay with them?
Integration Realities: Systems, APIs, and Data Access
- Identify every system that must integrate for go‑live, including storefront, order management, ERP, tax, loyalty, and who owns each connection.
- List which of those systems expose APIs or webhooks we can use today and which will require additional work or vendor involvement.
- Do you have a sandbox environment and realistic test data available for integration and authorization testing within the next 4 weeks?
- When must legal or compliance approvals be completed to allow access to production payment data?
- Estimate the number of engineers or integration resources you can commit during the core three weeks of integration.
- Can your team accept an alternate acceptance path if production API access is not possible within the planned timeline?
Governance, Compliance, and Financial Constraints
- Share any regulatory, PCI, or bank onboarding constraints that have previously delayed payment projects for your organization.
- Are there contractual, tax, or currency restrictions that would prevent standard settlement flows in certain countries?
- Do you already hold a current PCI attestation or will an external QSA review be required for our integration?
- Why would a delay in compliance or KYC materially change your go‑live timing or willingness to proceed?
- Name the specific finance or bank approvals that are mandatory before funds can settle to your account and who holds those approvals.
- Would inability to obtain necessary KYC or acquiring approval within 8 weeks cause you to pause all new payment vendor projects?
People and Process: Who Will Run This Day to Day
- List the day to day owners for chargebacks, reconciliation, fraud operations, and platform support, and how decisions escalate between them.
- Please provide the single point of contact for testing and indicate whether they have authority to approve go‑live.
- Can your teams be available for daily stand ups during integration and for rapid triage during the first week of live traffic?
- How many manual reviews per day can your operations team handle before approval throughput slows by more than 50 percent?
- In practice, can you guarantee a 30 minute escalation response for payment outages during business hours, or would you prefer a managed third party escalation?
Signals for Success and Decision Triggers
- Share the measurable metrics and thresholds that would make a pilot a clear success, for example approval lift, dispute ratio, or settlement timing.
- Provide your target tolerance levels for approval rate, dispute ratio, and settlement lag that the pilot must meet.
- Please indicate who on your side can approve scaling a successful pilot to full production and the expected approval timeframe.
- In the event the pilot proves the stated numbers, will procurement and finance be ready to sign a standard commercial agreement within two weeks?
- By roughly how soon after a successful pilot do you expect settlement and reconciliation to operate without manual intervention?
- Explain the minimal reporting and dashboard views you need to feel confident in day two operations.
- Will you commit to a pilot scope and timeline if the integration assumptions we discussed hold true?
-
-
Payments Solution Experience
Translate the buyer's goals into a shared vision of how authorization routing, fraud controls, settlement, and checkout integrations deliver the desired outcomes.
Solution Experience
- Payments Solution Experience
- Confirm the current state and its cost
- You confirm the restated current state and the quantified cost reflect your team's reality.
- Deliver a tailored proposal showing projected authorization approval uplift, expected fraud loss reduction, and settlement timing projections within five business days.
- You agree the demonstrated routing and fraud approach maps to the target outcomes and will materially reduce authorization declines and fraud losses.
- Define the target outcomes and success signals
- Provide a 7-day sample of transaction logs including failure reasons to enable routing and fraud simulation.
- You accept the proposed settlement and reconciliation handling as the basis for the integration acceptance criteria.
- Walk a tailored authorization and fraud scenario
- List any regulatory, treasury, or currency constraints that will affect settlement and reconciliation decisions.
- Review settlement, currency, and reconciliation handling
- Prepare an integration sandbox with sample routing rules and a runbook for a follow-up technical validation session.
- Validate the future state
- Payments Solution Experience
- Solution Experience Deck
- Solution Brief
- meeting
- slides
- document
-
Integration Scope
Define channels, payment methods, routing rules, currency and settlement requirements, fraud and chargeback handling, and clear responsibilities and acceptance criteria.
Scope Configuration
- Provision Merchant Account and Funding
- Online Card Acceptance Integration
- In‑Store POS Payment Integration
- Tokenization and PCI Compliance Enablement
- Authorization Routing Optimization
- Fraud Detection and Risk Rules Setup
- Digital Wallets Integration
- ACH and Alternative Payment Activation
- Multi‑Currency Processing Configuration
- Recurring Billing and Subscription Processing
- Marketplace and Split‑Payouts Implementation
- Chargeback and Dispute Management Setup
- Developer API Integration and Webhooks
- Settlement Reporting and Accounting Exports
- Real‑Time Settlement and Fast Funding Activation
Scope Questions
Provision Merchant Account and Funding
- Will you require a new merchant account (merchant ID) to be provisioned or will you provide an existing merchant ID (MID)?
- Provide the funding destination details your bank requires for payouts (bank name, account number format, ACH/IBAN requirement).
- How frequently do you require payouts to your bank (daily, same-day, weekly) and in which settlement currency should funds be delivered?
- Specify any bank-level validation required before first settlement (micro-deposit verification, instant account verification, or bank confirmation).
- What evidence will validate merchant account and funding readiness (for example: live MID issued, first successful settlement to the provided bank account, signed merchant agreement)?
Online Card Acceptance Integration
- Which checkout integration pattern will your web storefront use: redirect/hosted checkout, embeddable hosted fields, or API-driven card tokenization?
- List the frontend frameworks or single-page app architecture in use for your checkout (example: React single-page checkout, server-rendered pages).
- Estimate peak authorization throughput for your online channel (peak requests per second) and typical transaction size in USD or your primary currency.
- Which issuer-level anti-fraud signals should be preserved on the authorization flow (AVS result, CVV result, 3DS authentication result, device fingerprint ID)?
- Which test card behaviors or simulator scenarios do you need exercised before go-live (soft declines, issuer timeout, 3DS friction, network failover)?
In‑Store POS Payment Integration
- Which physical terminal types and connectivity do you plan to deploy at locations (EMV chip reader, NFC/contactless reader, integrated PIN pad, Ethernet vs Wi-Fi vs cellular)?
- Specify the POS integration method you will use: terminal SDK embedded in POS app, POS cloud API with terminal orchestration, or ISO 8583 direct integration.
- Provide expected terminal counts per location and peak transactions per terminal per hour for capacity planning.
- Identify the terminal certification or EMV kernel versions required by your acquirer or existing estate (for example EMV kernel v4.x, P2PE certificate ID).
- Which reconciliation artifact should confirm in-store integration success during pilots (authorized transaction sample vs settlement batch file match for test batch)?
Tokenization and PCI Compliance Enablement
- Which tokenization model do you require: client-side tokenization (to reduce PCI scope), server-side vaulting with tokens, or ephemeral one-time tokens for each session?
- Are you currently PCI DSS compliant and which Self-Assessment Questionnaire (SAQ) type do you file or expect to file (for example SAQ A, SAQ A-EP, SAQ D)?
- Specify which cardholder data elements you will store or need tokenized (PAN, cardholder name, expiry) and whether CVV will ever be stored (note: CVV should not be stored).
- Who is the internal owner for PCI attestations and which evidence repository do you use for SAQ artifacts (example: security@gteam, internal compliance portal)?
- What defines done for tokenization and PCI scope reduction (for example: no PAN in your checkout logs, token returned from vault in production, passing SAQ A attestation)?
Authorization Routing Optimization
- Which acquirer endpoints or route identifiers (acquirer IDs or BIN ranges) do you plan to route to or expect to include in routing tables?
- Specify the primary routing objective: maximize approval rate, minimize cost per authorization, or geo/issuer-based routing.
- How should failover be handled when an acquirer shows elevated decline rates (immediate failover, weighted routing, or manual intervention)?
- State the approval-rate or latency thresholds that should trigger a routing change (for example approval rate <95% for BIN range, or average latency > 500 ms).
- Which monitoring artifacts do you require after routing changes (authorization success-rate dashboard, per-BIN approval table, and 15-minute latency percentiles)?
Fraud Detection and Risk Rules Setup
- Which fraud signals must be included in the ruleset: AVS mismatch, CVV failure, velocity limits, device fingerprint ID, or BIN velocity?
- Specify the fraud score threshold that should automatically decline transactions and the score range that should route to manual review.
- Will you require third-party device fingerprinting or third-party identity verification integrations for high-risk transactions?
- Identify which chargeback reason categories should escalate to high-risk handling (fraud, authorization, product not received) and how many occurrences should trigger action.
- Specify tuning targets for fraud rules (target false-positive rate, target detection rate) to guide iterative rule adjustments.
Digital Wallets Integration
- Which wallet categories do you need to accept: mobile OS wallets for in-app, browser-based wallets for web checkout, or tokenized in-app wallets?
- Which payment token types do you expect to receive from wallets (network token, PAN token, or payment credential ID)?
- Provide the SDK or in-app framework your mobile app uses for wallet integration (for example: native iOS/Android frameworks or cross-platform SDK).
- How should fallback behave when wallet tokenization fails at checkout: prompt for PAN entry, offer alternate wallet, or block checkout?
- Who on your team will own wallet token lifecycle (token refresh, revocation) and provide necessary app store entitlements or merchant IDs?
ACH and Alternative Payment Activation
- Which alternative payment types should be enabled: ACH (bank debit), instant bank transfers, local bank payment methods, or cash-based collection options?
- For ACH origination, which verification method do you prefer: micro-deposits, instant account verification, or manual bank validation?
- Estimate expected ACH volume and per-transaction limits that should be configured for risk controls (daily and monthly dollar limits).
- Which NACHA record types or settlement file format do you require for bank reconciliation (ACH CCD, CTX, or custom CSV mapping)?
- Who will own returned item processing for ACH and the decision to reattempt or refund (operations, finance, or third-party service)?
Multi‑Currency Processing Configuration
- List the settlement currencies (ISO codes) you require for merchant payouts and reconciliations.
- Should currency conversion be offered at checkout as dynamic currency conversion or should conversion occur only at settlement?
- Provide acceptable FX markup tolerance or pass-through policy for converted transactions (for example: pass-through, up to 1%, custom).
- Which accounting fields must appear on multi-currency settlement reports for reconciliation (settled amount, original amount, FX rate, fee breakdown)?
- Identify any regulatory or local requirements for cross-border settlements you must meet (local tax reporting, VAT handling, local entity remittance).
Recurring Billing and Subscription Processing
- Which billing models will you run: fixed recurring plans, usage-based metering, or hybrid models requiring metered usage billing?
- Specify billing cadence and retry schedule you require for failed charges (for example monthly billing with retries at 1 day, 3 days, 7 days).
- How should failed recurring payments be handled: pause subscription, notify and retry, auto-cancel after X days, or downgrade plan?
- Which hosted billing features do you require: hosted customer portal for card updates, hosted checkout for subscription sign-up, or invoice email templating?
- Which invoice and subscription fields must appear for accounting and customer receipts (plan id, next billing date, proration line items)?
Marketplace and Split‑Payouts Implementation
- Which marketplace model describes your business: platform facilitator, payments aggregator, or peer-to-peer marketplace?
- Which split logic should apply to transactions: percentage-based split, fixed-fee per transaction, or tiered seller splits?
- Specify the KYC documents required for seller onboarding (examples: tax ID, bank account proof, government ID) and the verification level needed.
- What settlement cadence and holdback policy should apply to sub-merchants (for example daily payouts with 7-day holdback for dispute risk)?
- Who will be responsible for marketplace fee remittance and chargeback liability under your operational model (platform, sub-merchant, or shared)?
Chargeback and Dispute Management Setup
- Which chargeback reason categories should auto-trigger representment (fraud, authorization, service not rendered)?
- Which evidence artifacts can you provide for representment: transaction receipt PDF, AVS/CVV flags, signed delivery proof, or shipment tracking ID?
- Specify the SLA for dispute evidence assembly and submission once a chargeback is received (for example 24 hours, 72 hours).
- Who will own dispute handling workflows and communications with card networks (operations team, finance team, or outsourced provider)?
- Which KPIs should trigger an operational review for chargeback risk (chargeback-to-transaction ratio threshold, dollar disputed threshold)?
-
Commercial & Compliance Agreement
Finalize pricing model, contract modules, compliance responsibilities (PCI, data), and operational SLAs required to proceed.
Agreement Modules
- Master Services Agreement (MSA)
- Subscription & Order Form
- Statement of Work (SOW)
- Service Level Agreement (SLA)
- Data Processing Agreement (DPA)
- PCI Compliance Addendum
- Settlement & Funding Agreement
- Chargeback & Risk Management Policy
- Compliance Responsibility Matrix
- Exit & Transition Addendum
-
Deployment
Lock readiness facts and configuration values before execution begins.
-
Pre-Deployment Readiness
Confirm concrete readiness facts — environments, data access, owners, timelines, and go-live constraints the integration depends on.
Pre-Deployment Questions
Environment and access
- Which environments will the integration touch? (select all that apply)
- For any environment that is not immediately available, what is the earliest available date and one-line constraint (e.g., release freeze, access approval) — so we can schedule environment provisioning and cutover windows.
- Who will provision and be the primary owner of API credentials for non-production and production environments? (we will collect the actual keys in Configuration Details)
Data and configuration
- Who is the authoritative source of transaction and billing data the deployment must align with? (choose the primary owner)
- Will historical transaction or reconciliation data need migration or backfill before go‑live?
- Are routing, settlement currency choices, and chargeback assignment rules finalized so the deployment team can lock configuration? If not, choose the closest state.
People and ownership
- Provide named owners for these workstreams: technical integration lead, payments operations owner, business sponsor, and escalation contact (name, role, email). These will populate the deployment runbook.
- Are the required test and validation resources committed for the proposed go‑live week (integration engineer, QA tester, business validator)? Answer helps fix milestone dates.
Timing and constraints
- What is the confirmed target go‑live date or agreed launch window? If not fixed, provide earliest and latest dates.
- Are there known blackout windows, monthly financial close periods, or regulatory/compliance gates that will block deployment? (select all that apply)
- If you selected any blocking constraint above, list the specific dates/cycles and the owner responsible for resolution (one line per item) so we can plan around them.
-
Configuration Details
Capture exact integration values the deployment team will use — API keys, webhook endpoints, field mappings, settlement settings, and routing preferences.
Configuration Details
Environments & Endpoints
- Enter the Production API base URL the platform should call for live traffic (format: https://... — include path/version if required, e.g. https://api.yourdomain.com/v1). This exact value will be placed in the production connector settings.
- Enter the Sandbox API base URL the platform should call for testing (format: https://... — include path/version if required). This value is used by the test connector and integration tests.
Authentication & Webhooks
- Provide the production API key identifier (the non-secret name or client_id that references the key in your secrets manager). DO NOT paste the secret itself; the secret will be exchanged via the selected credential exchange method.
- Select the method you will use to deliver production secrets and signing keys to the seller at deployment kickoff (Default: Your secrets manager). The deployment team will not accept secret values in this sheet.
- Enter the webhook callback endpoint URL the buyer will expose to receive event notifications (format: https://...). This exact URL will be registered in the platform's webhook configuration.
- Select the webhook signing method the buyer will use to validate incoming events (Default: HMAC-SHA256 header). If you select a signed method, the key name/identifier will be collected below — do NOT paste the signing key.
- Webhook signing key identifier (the non-secret key name or ID in your secrets manager used for webhook signing). Do NOT paste the key; the secret itself will be exchanged via the chosen credential exchange method.
Mappings, Settlement & Routing
- Payment token field name in the buyer's checkout payload or webhook (Default: payment_token). Enter the exact field key the platform should map to the platform token.
- Primary settlement currency for this merchant account (ISO 4217 three-letter code — Default: USD). Enter the exact code to configure settlement ledger mapping.
- Select the authorization routing preference the seller should apply for this merchant account (Default: Highest-authorization-rate first). If you choose 'Custom routing rules' you will provide a rules file URL in the next step of the deployment flow.
-
Launch Execution
Execute onboarding and go-live with assigned owners, milestones, testing, and rollback/escalation paths.
-
-
Success
Validate outcomes against success signals, capture learnings, and maintain a shared channel for issues and improvement requests.
Success Reviews
- Go-live Health Check (weeks 1-4)
- First Measurement Review (weeks 4-10)
- Acceptance Gate Review (around day 90)
- Quarterly Success Review (ongoing)
Issues & Enhancements
- Add the prioritized enhancement requests to the operational backlog with rough effort estimates and target quarters.
- Open tracking tickets for each corrective action with owners and target dates.
- Restate acceptance criteria and numeric targets
- Produce a documented acceptance decision for the scoped targets recorded in Integration Scope, with pass/fail recorded per criterion.
- For any failed criteria, capture a remediation plan with owners and completion dates and a verification method.
- Confirm the incumbent system is either decommissioned or formally retained read-only with data handling actions recorded.
- Publish the acceptance report including raw evidence, pass/fail results, and the documented acceptance decision.
- Create remediation tickets for each failed criterion with owners, target dates, and verification steps.
- If incumbent is being decommissioned, publish the archive/retention record and the cutover confirmation.
- Quarter metrics and trend review
- Confirm whether authorization approval rate and settlement time to funds meet or are on plan against Integration Scope targets, or capture remediation plans where they do not.
- Reduce the active incident count by agreeing resolution dates for the top 5 open items.
- Prioritize and schedule the top 3 enhancement requests for the next quarter.
- Publish the quarter performance dashboard and annotate any deviations from Integration Scope targets with remediation plans.
- Assign resolution dates to the top 5 open incidents and update the shared tracker.
- Reconfirm success criteria and owners
- Confirm the integration environments, data access, and basic transaction flows are functioning as documented in Integration Scope.
- Identify and record the top 5 open issues with mitigation actions and target completion dates.
- Schedule the First Measurement Review and agree required data to be provided before that meeting.
- Publish a deployment health summary with environment checks, test-payment evidence, and open-issue list.
- Log each open issue in the shared tracker with an owner and target resolution date.
- Provide the dataset and date range required for the First Measurement Review.
- Present first-period performance data
- Establish whether authorization approval rate and chargeback rate are trending toward the targets recorded in Integration Scope.
- Document the top 3 root causes for any metric gaps and the corrective actions with owners and completion dates.
- Confirm the data package and timeline that will be used for the Acceptance Gate measurement.
- Implement agreed routing or fraud-rule changes and report status before the Acceptance Gate data freeze.
- Deliver the acceptance-period dataset and supporting logs to the shared workspace by the agreed date.
- Present outcome data against each criterion
- Open incident and ticket burn-down
- Deployment and migration validation
- Diagnose root causes for gaps
- Document pass or fail per criterion and record the acceptance decision
- Early adoption signals and usage patterns
- Enhancement request prioritization
- Agree corrective actions and owners
- Blockers and open issues triage
- Confirm timeline to Acceptance Gate
- Operational SLAs and escalation paths review
- Agree remediation plan for failed items
- Agree immediate remediation actions
- Incumbent system wind-down check
- Close items and schedule next checkpoint