← All guides

Gantt Chart for Payment Processing Implementation

Implement a payment processor with a Gantt chart. Timeline covers vendor selection, PCI DSS, API integration, UAT, and go-live cutover.

Gantt Chart for Payment Processing Implementation

Payment processing implementations fail on schedule more often than nearly any other technical project. The reasons are consistent: PCI DSS compliance requirements take longer than anticipated, bank account and MID (Merchant ID) setup involves external parties with unpredictable timelines, and fraud rule configuration is always underestimated. A Gantt chart with accurate lead time assumptions and proper dependency tracking is the difference between a payment rollout that goes live as planned and one that pushes the launch date twice.

This guide walks through the full payment processor implementation timeline — from requirements through first 30-day monitoring — with the task dependencies and parallel tracks that compress timeline without sacrificing compliance.

Phase 1: Requirements Gathering (Weeks 1–2)

Before evaluating vendors, document what you actually need. Payment requirements are more complex than "accept credit cards."

Payment methods:

  • Credit and debit cards (Visa, Mastercard, Amex, Discover — which networks matter for your market?).
  • ACH / bank transfer (US) or SEPA (EU) — critical for B2B transactions.
  • Digital wallets: Apple Pay, Google Pay, PayPal.
  • Buy Now Pay Later (BNPL): Klarna, Afterpay, Affirm — increasingly expected in e-commerce and SaaS with annual billing.
  • Local payment methods if you operate in multiple countries (iDEAL in Netherlands, Boleto in Brazil, Konbini in Japan).

Volume and transaction profile:

  • Expected monthly transaction volume and average transaction size.
  • Percentage of recurring vs. one-time transactions.
  • Percentage of international transactions.
  • Refund and chargeback rates from current processor (if migrating).

Currency requirements:

  • Do you charge in local currencies or single currency?
  • Who bears FX risk?

Integration requirements:

  • Will payments be embedded in your product (iFrame or hosted fields)?
  • Does your billing system or ERP need to receive transaction data? (Stripe → NetSuite, Salesforce CPQ → Zuora, etc.)
  • Do you need subscription billing management or one-time checkout only?

Document requirements as a functional specification. This becomes the foundation for vendor evaluation and the acceptance criteria for UAT.

Phase 2: Vendor Selection and Contract Negotiation (Weeks 2–5)

Major payment processors differ significantly in pricing model, geographic coverage, fraud tools, developer experience, and enterprise features.

Primary options:

  • Stripe: Best developer experience, fastest integration, strong ecosystem of pre-built integrations. Pricing is interchange-plus or flat rate (2.9% + 30¢). Enterprise contracts available at custom pricing.
  • Braintree (PayPal): Strong for marketplaces and platforms. Good PayPal and Venmo integration. Part of PayPal ecosystem.
  • Adyen: Strong for enterprise and international. Multi-currency, local payment methods, direct acquirer relationships. Higher implementation complexity.
  • Square: Best for in-person retail and food service. Less suited for pure e-commerce or SaaS.
  • Checkout.com: Strong in Europe and Middle East. Good for high-volume enterprise.

Contract negotiation tasks:

  • Obtain pricing proposals from 2–3 shortlisted processors.
  • Negotiate: interchange-plus vs. flat rate, monthly minimums, chargeback liability terms, PCI compliance fee, early termination fees.
  • Finalize and execute contract.

Allow 2–3 weeks for contract negotiation, especially for enterprise agreements with custom pricing.

Phase 3: PCI DSS Compliance Assessment (Weeks 3–7, Parallel with Vendor Selection)

PCI DSS (Payment Card Industry Data Security Standard) compliance is not optional — it is a contractual requirement of accepting card payments. The scope and effort depend on your integration approach.

SAQ (Self-Assessment Questionnaire) type determination:

  • SAQ A: You redirect to a hosted payment page (Stripe Checkout, PayPal redirect). Lowest scope — cardholder data never touches your servers.
  • SAQ A-EP: You use iFrame or JavaScript-based card fields but host the checkout page. Moderate scope.
  • SAQ D: You fully control the card data flow (rare, requires tokenization). Highest scope and effort.

Most SaaS and e-commerce companies should design toward SAQ A or SAQ A-EP to minimize compliance scope.

Scope reduction strategy:

  • Never store raw card numbers. Use your processor's tokenization.
  • Use hosted fields or payment elements that inject into your page but render from the processor's domain.
  • Segment your payment infrastructure from other internal systems.

Tasks:

  • Engage a QSA (Qualified Security Assessor) or use your processor's built-in compliance tools (Stripe has SAQ A-EP automation).
  • Complete the applicable SAQ.
  • Remediate any gaps identified.
  • Attest to compliance annually.

Phase 4: Technical Integration (Weeks 5–10)

The technical integration spans API configuration, frontend payment UI, webhook handling, and back-office system connections.

Integration tasks:

  • API documentation review and environment setup: Set up sandbox/test credentials. Assign API keys to secrets management (never hardcoded in source).
  • Frontend payment UI: Implement hosted payment fields, card element, or redirect flow depending on your SAQ approach. Test on all target browsers and devices.
  • Payment intent / charge creation flow: Implement server-side API calls for creating payment intents, handling 3DS authentication challenges, and confirming charges.
  • Webhooks: Configure webhook endpoints to receive asynchronous events: payment succeeded, payment failed, charge refunded, dispute created. Implement idempotency handling — webhook events can be delivered more than once.
  • Subscription billing (if applicable): Configure products, prices, and subscription schedules in the processor's billing system. Test proration, plan changes, and cancellations.
  • ERP / billing system integration: Connect payment events to your financial system of record. Typically requires a middleware service or iPaaS connector.

Track each integration component as a separate Gantt row — they can be built in parallel but all must complete before UAT begins.

Phase 5: Fraud Rules Configuration (Weeks 8–10)

Fraud configuration is consistently underestimated. Default fraud rules protect against common attacks but need tuning for your specific transaction profile.

Fraud tools by processor:

  • Stripe Radar: Machine learning-based fraud scoring with configurable rules. Free tier plus premium Radar for Fraud Teams.
  • Braintree / Kount: Kount integration for behavioral analytics and device intelligence.
  • Adyen RevenueProtect: Built-in ML fraud protection with manual rule configuration.

Rules to configure:

  • Velocity rules: Block cards used more than N times per hour across your platform.
  • 3DS2 (3D Secure 2): Trigger step-up authentication for high-risk transactions. Configure risk thresholds carefully — over-triggering 3DS reduces conversion.
  • Address Verification (AVS): Decline or flag transactions where billing address does not match.
  • CVC verification: Always require CVC for card-not-present transactions.
  • Blocklists: Block known fraudulent email domains, IPs, and card BINs.

Run fraud rule configuration through your sandbox with test card data covering all edge cases before production.

Phase 6: Bank Account and MID Setup (Weeks 3–8, Long Lead Time)

Merchant account and bank payout setup involves your bank, the processor, and sometimes card networks directly. This is the most variable timeline item in the entire project.

Tasks:

  • Submit business verification documents to your processor (business registration, tax ID, beneficial ownership, bank account details for payouts).
  • Bank account verification (micro-deposit verification or instant verification via Plaid).
  • Payout schedule configuration (daily, weekly, or monthly payouts — affects working capital).
  • Reserve requirements (some processors hold a percentage of transactions as reserve for new merchants with limited history).

Start this process in parallel with technical integration. Do not let bank setup be on the critical path of your launch.

Phase 7: UAT with Test Cards and Edge Cases (Weeks 10–12)

User Acceptance Testing for payments must be exhaustive. Untested edge cases in production become chargebacks, failed payouts, and accounting discrepancies.

UAT test matrix:

  • Successful payment: Visa, Mastercard, Amex — all card types.
  • Declined payment: Insufficient funds, card blocked, expired card, incorrect CVC.
  • 3DS authenticated payment: Test cards that trigger 3DS challenge flow.
  • Partial authorization: Card authorized for less than the requested amount (common with prepaid cards).
  • Refund: Full refund, partial refund, refund after payout has been sent.
  • Dispute simulation: Initiate a simulated dispute and verify your dispute response workflow.
  • Subscription: Create, update plan, pause, cancel, and reactivate.
  • International: Test with non-US card BINs if accepting international payments.
  • Webhook reliability: Simulate webhook delays and duplicate deliveries to verify idempotency.

Document every test case, expected result, and actual result. All test cases must pass before go-live approval.

Phase 8: Go-Live Cutover Plan (Week 12)

A cutover plan answers: how do you switch from your current payment method (or no payment system) to the new processor without losing transactions or double-charging customers?

Cutover tasks:

  • Switch API keys from test/sandbox to production.
  • Verify production webhook endpoints are configured and receiving events.
  • Run a single live test transaction with a real card and verify payout receipt.
  • Migrate any active subscriptions from old processor to new (requires careful sequencing — cancel in old system, re-create in new with trial period to avoid double billing).
  • Decommission or suspend old processor integration.
  • Monitor error rates and decline rates in the first hour post-cutover.

Phase 9: Staff Training (Week 11–12, Parallel with UAT)

Train two groups:

Support team: How to look up transactions in the processor dashboard, issue refunds, respond to disputes (chargebacks) within the processor's required timeframe (typically 7–14 days), and identify fraud patterns.

Finance team: How to reconcile processor payouts to bank deposits, understand the payout timing schedule, identify and categorize fees, and handle the dispute reserve impact on cash flow.

Phase 10: First 30-Day Monitoring

The first month live is not business as usual. Monitor daily:

  • Authorization rate: What percentage of attempted transactions succeed? A rate below 90% on domestic cards warrants investigation.
  • Decline rate by decline code: High rates of "do not honor" or "insufficient funds" may indicate fraud attack. High "card blocked" may indicate incorrect fraud rule configuration.
  • Dispute rate: Must stay below 1% of transactions (Visa threshold) to avoid processor scrutiny.
  • Payout reconciliation: Verify every payout matches your expected amount.
  • 3DS challenge rate and abandonment: Overly aggressive 3DS triggering drops conversion.

Set up automated alerts in your monitoring tool (Datadog, Grafana, or processor-native dashboards) for threshold breaches. Review daily for 30 days, then weekly.

Building Your Payment Processing Gantt Chart

In gantt-chart.io, map these phases with their parallel tracks:

  • Vendor selection and PCI assessment run simultaneously (Weeks 2–7).
  • Bank account setup starts early and runs alongside technical integration.
  • Fraud configuration and ERP integration are parallel tracks within the technical integration phase.

Mark go-live as a hard milestone with dependencies on: UAT completion, bank account active, PCI attestation complete, and staff training done. A payment implementation that launches before all four are ready will generate incidents that take weeks to resolve.