How Payment Gateways Work: Transaction Flow, APIs, and Settlement Explained
A payment gateway is not a checkout button. It is a 7-step transaction pipeline that authenticates, routes, scores, and settles every card payment in under 2 seconds. Here is exactly how it works.
Ahmed Ginani
QUICK ANSWER - What Is a Payment Gateway? A payment gateway is a software layer that captures, encrypts, authenticates, and routes card payment data between a customer, a merchant, and the banking network, returning an authorization or decline in under 2 seconds. It is not a checkout form. It is the entire regulated pipeline that makes digital money movement possible. A custom payment gateway development cost starts at $8,000–$14,000/month for a 2–3 engineer team at Acquaint Softtech. Typical MVP timeline: 8–14 weeks. |
As Head of Partnerships at Acquaint Softtech, a payment gateway development company, Indian clients across the US, UK, Australia, and UAE trust me, with over 1,300+ projects delivered, I review payment architecture decisions every week. The single most common mistake I see is founders treating a payment gateway as a feature, when it is actually a regulated infrastructure layer that determines the security posture, compliance scope, and transaction reliability of their entire product.
This guide covers everything: what a payment gateway actually is, the 7-step transaction flow most developers do not see, the APIs that connect to it, how settlement works, what the payment gateway development cost looks like in 2026, and how to decide whether to build custom, integrate existing, or use a hybrid approach. The master reference is the complete guide to finTech software development in 2026. This article goes deep into payments specifically.
- You are a founder or CTO evaluating whether to build a custom payment gateway or integrate Stripe/Razorpay, and you need to understand what you are actually choosing between.
- You are a product manager who keeps hearing terms like tokenization, 3DS2, acquiring bank, and interchange, but needs them explained in plain operational terms.
- You are scoping a payment gateway feature for an eCommerce platform, marketplace, or SaaS product and need to understand the compliance surface before the first sprint.
- You are evaluating payment gateway development company India options and want to know what technical questions to ask before signing a contract.
What a Payment Gateway Actually Is And What It Is Not
Most people think of a payment gateway as a checkout button or a payment form. That mental model is wrong, and it leads to the wrong architecture decisions. A payment gateway is a regulated software intermediary that sits between the merchant's product and the global banking infrastructure. It handles five distinct functions that must each work correctly, every time, in under 2 seconds.
01 | Data Capture and Encryption The gateway captures card credentials, Primary Account Number (PAN), expiry date, and CVV at the point of entry, immediately encrypts them using TLS 1.3, and passes them downstream as an encrypted payload. The raw card number must never be stored. This is not a security recommendation; it is a PCI-DSS requirement. |
02 | Tokenisation The raw PAN is replaced with a surrogate token, a randomly generated identifier that maps to the original card number only inside the token vault, which is either hosted by the gateway provider (Stripe, Braintree) or by a dedicated tokenization service with HSM (Hardware Security Module) key management. Tokens can be stored safely. PAN cannot. |
03 | Authentication (3DS2) The payer's identity is verified via 3-Domain Secure 2.0 (3DS2), which performs a risk-based challenge: low-risk transactions pass through frictionlessly; higher-risk transactions trigger an additional authentication step (OTP, biometric). Required for all EU/UK transactions under SCA (Strong Customer Authentication) regulations. |
04 | Routing and Authorization The encrypted, tokenized transaction is routed to the acquiring bank, which forwards it to the card network (Visa, Mastercard). The card network routes it to the issuing bank (the customer's bank). The issuing bank checks the customer's balance and fraud signals, then returns an authorization code or a decline code. Total round-trip: 800ms–1,500ms. |
05 | Settlement Authorization and settlement are different events. Authorization reserves the funds, while settlement actually moves the money from the issuing bank through the card network to the acquiring bank, minus interchange fees. This settlement usually happens in a batch process overnight. For businesses managing these complex payment workflows, it is important to hire a project manager to ensure smooth coordination between banking systems, payment gateways, and reconciliation processes. The merchant then receives the net amount, typically within T+1 to T+3, depending on the card network and the acquiring bank relationship. |
Payment Gateway vs Payment Processor vs Payment Service Provider: The Definitions
Payment Gateway: The software layer that handles data capture, encryption, tokenization, 3DS2, and routing. Examples: Stripe Gateway, Braintree, custom-built.
Payment Processor: The entity that handles the actual card network communication and clearing. Often, the acquiring bank itself or a third-party processor (TSYS, WorldPay). Stripe combines a gateway + processor in one API.
Payment Service Provider (PSP): A bundled solution that provides a gateway, processing, and merchant account in one service. Stripe, Square, Razorpay, and PayPal are PSPs. Simplest for early-stage products.
Acquiring Bank: The merchant's bank, the institution that receives funds from the card network on behalf of the merchant and deposits the net amount after fees.
Issuing Bank: The customer's bank, the institution that issued the card being used for the transaction and makes the authorization decision.
The 7-Step Payment Gateway Transaction Flow (What Actually Happens in 2 Seconds)
Most payment integration tutorials show you how to call the Stripe API. They do not show you what happens after that API call is made. The 7-step flow below traces a card-not-present transaction, the most common type in digital products, from the customer entering card details to the merchant receiving funds, with the actor responsible for each step clearly identified.
Step 1: Customer Enters Card Details |
ACTOR: Merchant frontend / Payment gateway hosted fields The customer enters card number, expiry, and CVV into either a merchant-hosted form or the gateway's hosted fields (e.g. Stripe Elements). Hosted fields are the preferred approach: card data goes directly to the gateway's servers, never touching the merchant's. This alone reduces the PCI-DSS scope from SAQ D to SAQ A. |
Step 2: Tokenization and Encryption |
ACTOR: Payment gateway The gateway immediately tokenizes the PAN and encrypts the entire payload using TLS 1.3. A transaction object is created with a unique idempotency key, a critical detail that prevents duplicate charges if a network timeout causes the merchant to retry the request. |
Step 3: 3DS2 Risk Assessment |
ACTOR: Payment gateway + issuer ACS (Access Control Server) The gateway sends transaction attributes, amount, device fingerprint, velocity signals, and shipping address to the issuer's ACS. Low-risk transactions (flagged as frictionless) proceed immediately. Higher-risk transactions trigger a challenge step (SMS OTP, biometric). This step takes 200–600ms. |
Step 4: Authorisation Request to Acquirer |
ACTOR: Gateway → Acquiring bank The gateway forwards the authorisation request to the acquiring bank (the merchant's bank) in ISO 8583 or an equivalent message format. The acquirer validates that the merchant's account is in good standing and forwards the request to the card network. |
Step 5: Card Network Routing |
ACTOR: Card network (Visa/Mastercard) The card network (Visa, Mastercard, Amex, etc.) routes the authorization request to the issuing bank (the customer's bank). The network applies its own fraud checks and routing logic, adding 50–150ms to the total latency. |
Step 6: Issuer Authorisation Decision |
ACTOR: Issuing bank The issuing bank checks: available balance, fraud signals (velocity, geography, merchant category), card status (not blocked/expired), and 3DS verification result. It returns an authorization code (approved) or a decline code. Response codes are standardized: 00 = approved; 05 = do not honour; 51 = insufficient funds; 14 = invalid card number. The merchant receives the specific decline code, not the customer. |
Step 7: Settlement (T+1 to T+3) |
ACTOR: Card network + Acquiring bank + Merchant bank Authorization is not a settlement. Settlement happens in a batch process, typically overnight. The card network calculates net positions across all transactions for the day, the issuing bank transfers funds to the card network, the card network transfers to the acquiring bank, and the acquiring bank deposits the net amount (transaction amount minus interchange fee, gateway fee, and processor markup) into the merchant's account. For businesses scaling complex payment infrastructure, leveraging expert guidance, such as virtual CTO services, can help design efficient settlement workflows and optimize transaction cost management. |
Regulatory Reference
The UK FCA's payment services regulatory framework governs Step 3 (SCA requirements) and Step 7 (settlement timing obligations) for UK-based merchants. See the FCA Payment Services Regulations guide for the authoritative source. For India: the RBI Payment Aggregator Guidelines (RBI/2019-20/249) govern payment gateway licensing and escrow requirements for PA/PG operators.
Building a Payment Flow? Start With the Right Architecture.
Acquaint Softtech's payment platform team delivers architecture reviews, PCI-DSS scope assessments, and integration plans within 48 hours. 1,300+ projects. 43 Clutch reviews. You interview before you commit.
Payment Gateway APIs: What They Expose and How Developers Integrate Them
A payment gateway exposes its functionality through APIs. Understanding the API surface tells you what a gateway can and cannot do, and what your development team needs to build around it. If your platform also relies on advanced automation, fraud detection, or smart decision-making, it may require expertise similar to teams you would typically hire AI/ML engineers for. The five API categories below cover the complete integration surface of any modern payment gateway.
API Category | What It Does | Key Parameters | Critical Detail |
Payment Intents API | Creates and manages a payment transaction object. Handles the full lifecycle: creation → 3DS challenge → confirmation → capture. | amount (integer, smallest unit), currency, payment_method, confirm, capture_method | Amount must be an integer. $12.50 = 1250 (pence/cents). Never float. |
Payment Methods API | Tokenizes and stores card details. Returns a payment method ID that replaces the raw card number for future charges. | card object, billing_details, customer (for saved cards) | Payment method IDs are one-time use unless attached to a customer object for reuse. |
Webhooks API | Sends real-time event notifications to the merchant's server. Critical for handling async events: payment succeeded, payment failed, dispute created. | endpoint_url, event_types, signing_secret | All webhooks must be signature-verified (HMAC-SHA256) before processing. Unverified webhooks are a security vulnerability. |
Refunds API | Initiates full or partial refunds on completed charges. Refunds are separate transactions; the original charge is not reversed. | charge_id, amount (optional, omit for full refund), reason | Refunds to debit cards typically arrive in 5–10 business days. Credit cards: 5–7 days. Instant refunds require a separate feature flag. |
Disputes API | Manages chargeback workflow. Retrieves dispute details, submits evidence, and tracks status. | dispute_id, evidence object (shipping, customer communication, etc.), submission deadline | The evidence submission deadline is typically 7–21 days from dispute creation. Missing the deadline = automatic loss. |
Idempotency Keys - The Most Important API Parameter Nobody Talks About
Every payment API call that creates or mutates a transaction must include a unique idempotency key, a client-generated string that the gateway uses to recognize and safely retry duplicate requests. If a network timeout causes the merchant server to retry a charge without an idempotency key, the customer gets charged twice. This is one of the most common payment integration bugs in production systems, and it is entirely preventable by including an idempotency key on every request that changes state.
Implementation pattern: use a UUID generated at the start of the checkout session as the idempotency key. Store it in the session. On any retry of the same payment attempt, use the same key. The gateway returns the original response, no duplicate charge.
Webhook Signature Verification The Security Step Most Tutorials Skip
Webhooks are HTTP POST requests from the gateway to your server. Any system on the internet can send an HTTP POST. Without signature verification, an attacker can send a fake 'payment succeeded' event and trigger order fulfillment without paying. The signature verification pattern: (1) retrieve the raw request body before any JSON parsing; (2) retrieve the signing secret from your environment variables, not from the request; (3) compute HMAC-SHA256 of the raw body using the signing secret; (4) compare the computed signature to the one in the request header using a constant-time comparison function (timing-safe equals). If the signatures do not match, return 400 and log the attempt.
Build vs Integrate vs Hybrid: The Payment Gateway Decision Framework
The most important payment gateway architecture decision is not which gateway provider to use. It is whether to build a custom gateway, integrate an existing provider's API, or take a hybrid approach. The answer depends on four variables: transaction volume, PCI-DSS scope tolerance, product differentiation requirements, and regulatory geography.
Dimension | Integrate (Stripe/Razorpay/Adyen) | Hybrid (PSP + Custom Logic) | Build Custom Gateway |
Transaction volume | Any volume, PSPs scale automatically | Medium to high (>$500K/month GMV) | Very high (>$50M/month GMV), where PSP fees are uneconomic |
Time to production | 2–6 weeks for basic integration | 8–16 weeks | 6–18+ months |
PCI-DSS scope | SAQ A (lowest) with hosted fields | SAQ A if using hosted fields; SAQ D if custom card capture | Level 1, full QSA audit required ($15K–$50K/year) |
Monthly cost | PSP fees: 1.4%–2.9% + $0.20–$0.30 per transaction | PSP fees + team cost ($8K–$18K/month) | Full infrastructure + team ($35K–$65K/month) |
Fraud control | PSP's fraud engine (Stripe Radar, etc.) | Custom rules on top of PSP signals | Full custom ML model, complete control |
Merchant customisation | Limited to PSP's product surface | Moderate, custom orchestration on PSP infrastructure | Complete — any routing logic, any acquiring bank, any currency |
Best for | Startups, SaaS products, marketplaces under $10M GMV/year | Growing marketplaces, B2B platforms needing custom flows | Payment service providers are building their own gateway product |
Decision Principle
The correct decision for 90% of digital products in 2026 is integration, not custom build. Stripe's transaction fees (1.4%–2.9%) are economically superior to the cost of building and maintaining a custom gateway until GMV exceeds approximately $50M–$100M/year, at which point interchange savings begin to justify the engineering investment. The only non-volume reason to build custom is if your product is a payment gateway - you are building a PSP, not a product that uses one.
Payment Gateway Features List: What Must Exist at Launch vs What Can Wait
Payment gateway features are not a backlog to be prioritized arbitrarily. Some features must exist before the first live transaction. Others can be added in subsequent sprints. Shipping a payment gateway without the “must exist at launch” features is not an MVP; it is a security and compliance liability. This is where a reliable staff augmentation partner can help you quickly fill skill gaps and ensure critical features are built correctly from day one, without delaying your launch.
Feature | Category | Must Exist at Launch? | If Missing... |
Tokenisation (PAN replacement) | Security / PCI-DSS | YES - mandatory | Storing raw card numbers: immediate PCI-DSS violation. $5K–$100K fine per incident. |
TLS 1.3 encryption in transit | Security / PCI-DSS | YES - mandatory | All payment data is exposed in transit. PCI-DSS Req 4 violation. |
Idempotency keys on all mutations | Data integrity | YES - strongly required | Duplicate charges on network retries. Customer disputes, refund costs, and trust damage. |
Webhook signature verification | Security | YES - strongly required | Fraudulent 'payment succeeded' events can trigger order fulfilment without payment. |
3DS2 authentication | Compliance (EU/UK/India) | YES for EU/UK transactions | SCA non-compliance. Liability for disputed transactions shifts entirely to the merchant. |
Fraud scoring (basic) | Risk | YES - pre-launch required | No fraud control on live transactions. First-week fraud losses can exceed the gateway build cost. |
Settlement reconciliation | Finance / Operations | YES - at launch | Manual reconciliation does not scale past ~50 transactions/day. Accounting errors accumulate. |
Decline code handling (all codes) | UX / Operations | YES - at launch | Generic 'payment failed' gives users no recovery path. Cart abandonment rate increases significantly. |
Multi-currency support | Product | Only if international | Required if accepting payments in multiple currencies — otherwise defer to add currency in sprint 2+ |
Saved payment methods | UX / Conversion | No - can be Sprint 2 | Increases conversion rates by 15%–30%, but not a compliance requirement for the initial launch. |
Subscription billing | Product | Only if required | Required for SaaS products; not required for one-time checkout flows. |
Instant payouts (to sellers) | Marketplace feature | No - add post-MVP | Required for mature marketplaces; needs additional regulatory setup (disbursement rails). |
Acquaint Softtech's software product development engagements for payment platforms include a pre-sprint feature classification exercise that maps every proposed feature to one of three categories: compliance-mandatory, launch-required, and post-MVP. This prevents the common mistake of building Saved Cards before building Webhook Signature Verification.
Scoping a Payment Gateway? Get a Feature Classification in 48 Hours.
Share your product brief, and Acquaint Softtech returns a prioritized payment gateway feature list, mandatory vs launch-required vs post-MVP, within 48 hours. Our MERN stack and payment specialists have built payment infrastructure for clients across the US, UK, Australia, and UAE.
Payment Gateway Tech Stack in 2026: What to Build With and Why
The payment gateway tech stack decision is driven by three requirements: sub-200ms API response time for the transaction endpoint, ACID-compliant data storage for financial records, and a security architecture that can pass PCI-DSS assessment. These requirements narrow the field significantly.
Layer | Technology | Why for Payments | Alternative |
API Layer (transaction processing) | Node.js or Python | Non-blocking I/O handles thousands of concurrent transaction requests without thread overhead. FastAPI adds automatic OpenAPI docs for team velocity. | Go (Gin), marginally faster, steeper learning curve. Java (Spring Boot) is better for core banking, but slower iteration. |
Background processing (settlement, notifications) | Python or Node.js | Async task queues handle settlement batch processing, webhook delivery retries, and fraud score batch updates without blocking the transaction API. | Apache Kafka for very high-volume (>1M transactions/day) event streaming. |
Primary database (financial ledger) | PostgreSQL | ACID compliance required. Row-level locking for concurrent balance updates. JSON columns for metadata. Native support for financial audit patterns. | MySQL (acceptable). MongoDB (not suitable, no ACID across multi-document transactions for financial data). |
Cache and rate limiting | Redis | Session tokens, rate limiting on payment endpoints (prevent card testing attacks), and idempotency key storage (TTL-based deduplication). | Memcached (simpler but lacks TTL precision needed for idempotency deduplication). |
Fraud scoring (ML layer) | Python | Real-time feature scoring in <50ms using pre-trained gradient boosting models. Feature store feeds real-time transaction signals. | Stripe Radar (sufficient for most products, only build custom at >$10M GMV/month). |
Frontend / Merchant Dashboard | React JS + TypeScript | Component reuse across transaction views, reconciliation dashboards, dispute management. Type safety catches currency handling bugs at compile time. | Vue.js (comparable). Avoid vanilla JS for financial dashboards; type safety is critical. |
Mobile payments | React Native | Single codebase for iOS and Android. Biometric payment confirmation (Face ID/fingerprint). Secure enclave integration for card tokenization on the device. | Flutter (comparable cross-platform capability). |
Infrastructure | AWS | PCI-DSS compliant managed services. WAF (Web Application Firewall) for API endpoint protection. RDS PostgreSQL with automated failover. | GCP (comparable). On-premise data centre for jurisdictions requiring data localization (India RBI, China regulations). |
Key management | AWS KMS or on-premise HSM | Encryption key rotation, HSM-backed storage for cardholder data encryption keys. Required for SAQ D and Level 1 PCI-DSS. | Azure Key Vault. On-premise Thales/nShield HSM for maximum control. |
For the application layer above the payment processing backend, Acquaint Softtech builds on Laravel as an Official Laravel Partner. Laravel's queue system, event broadcasting, and notification channels handle the merchant dashboard, reconciliation workflows, and admin tooling efficiently.
The MERN stack developers handle the real-time merchant analytics and dispute management interfaces, while Python developers build the fraud scoring ML layer. The DevOps engineering team manages the PCI-DSS-compliant infrastructure and CI/CD pipeline as a standard component of all payment gateway engagements.
Payment Gateway Development Cost in 2026: Real Numbers
Payment gateway development cost in 2026 has three components: engineering team cost, third-party integration and compliance cost, and ongoing operational cost. Most cost guides only cover team costs. All three components must be budgeted before the first sprint begins.
Tier 1 - Stripe/PSP Integration Layer Integrating Stripe, Razorpay, or Adyen into an existing product. Custom merchant dashboard, reconciliation, webhook handling, and fraud rule configuration. No custom card storage. |
Team: 2–3 engineers (1 backend, 1 frontend, 0.5 DevOps) |
Monthly Team Cost: $8,000–$14,000/month (Acquaint Softtech) |
Equivalent In-House: $22,000–$35,000/month |
Annual Saving: $168,000–$252,000 vs in-house |
MVP Timeline: 6–10 weeks |
PCI-DSS Scope: SAQ A (self-assessment, ~$0 audit cost) |
PSP Fees: 1.4%–2.9% + $0.20–$0.30 per transaction (Stripe UK/EU rates) |
Tier 2 - Custom Payment Gateway Layer on PSP Infrastructure Custom orchestration layer on top of a PSP. Multiple acquiring bank routing, custom fraud rules, split payments, marketplace payouts, white-label checkout. |
Team: 4–5 engineers (backend, frontend, fraud ML, DevOps, QA) |
Monthly Team Cost: $18,000–$28,000/month |
Equivalent In-House: $48,000–$65,000/month |
Annual Saving: $360,000–$444,000 vs in-house |
MVP Timeline: 12–18 weeks |
PCI-DSS Scope: SAQ A or SAQ C - depends on card data flow |
One-Time Costs: Security pen test: $8K–$20K; Legal review: $5K–$15K |
Tier 3 - Full Custom Payment Gateway (PSP Product) Building a payment gateway product for other merchants. Custom card vaulting, direct acquiring bank connection, multi-currency, full fraud engine, and scheme registration. |
Team: 7–10 engineers + project manager + security specialist |
Monthly Team Cost: $35,000–$55,000/month |
Equivalent In-House: $95,000–$150,000/month |
Annual Saving: $720,000–$1,140,000 vs in-house |
MVP Timeline: 24–40 weeks |
PCI-DSS Scope: Level 1 - QSA audit required: $15,000–$50,000/year |
One-Time Costs: HSM hardware/cloud: $10K–$30K; Legal/licensing: $20K–$100K+ |
Third-Party Costs: Budget Separately
• 3DS2 provider (if not bundled with PSP): $0.01–$0.05 per authentication
• KYC/identity verification for merchant onboarding: $1–$5 per verification
• Fraud score API (if not using PSP's built-in): $0.001–$0.01 per transaction scored
• Currency conversion data: $50–$500/month depending on depth and frequency
•Chargeback management tool (optional): $50–$500/month SaaS fee
The rate Acquaint Softtech charges is the rate, with no additional employer overhead, no hidden costs. All rates include tech lead, QA, and DevOps as standard. For hiring dedicated MERN stack developers for payment integration, React Native developers for the mobile payment interface, or Django developers for the backend payment API, the first developer is deployed within 48 hours of engagement confirmation.
Ready to Build Your Payment Gateway? Talk to a Team That Has Done It.
Acquaint Softtech has delivered payment gateway integrations and custom payment platforms for clients across the US, UK, Australia, and UAE. Share your brief, and we will return a team structure and cost estimate within 48 hours. You interview before you commit. No engagement required for the estimate.
Frequently Asked Questions
-
What is a payment gateway and how does it work?
A payment gateway is a software intermediary that processes card payments between a customer, a merchant, and the banking network. It captures card data, encrypts it, tokenizes the card number, performs 3DS2 authentication, routes the authorization request through the card network to the issuing bank, receives the authorization decision, and initiates settlement. The full process takes under 2 seconds. The gateway never stores raw card numbers; it replaces them with tokens immediately upon capture.
-
How much does payment gateway development cost in 2026?
A Stripe/PSP integration layer costs $8,000–$14,000 per month with Acquaint Softtech for a 2–3 engineer team, with an 8–14 week MVP timeline and SAQ A PCI-DSS scope. A custom orchestration layer on PSP infrastructure costs $18,000–$28,000 per month for a 4–5 engineer team over 12–18 weeks. A full custom payment gateway product costs $35,000–$55,000 per month for a 7–10 engineer team, requires a Level 1 PCI-DSS QSA audit ($15,000–$50,000/year), and takes 24–40 weeks to MVP. Third-party costs, fraud scoring, KYC, and 3DS2 are budgeted separately.
-
What features does a payment gateway need?
Non-negotiable at launch: tokenization, TLS 1.3 encryption in transit, idempotency keys on all mutation requests, webhook signature verification (HMAC-SHA256), 3DS2 authentication (mandatory for EU/UK transactions under SCA), basic fraud scoring, settlement reconciliation, and comprehensive decline code handling. Post-MVP: saved payment methods, subscription billing, multi-currency, instant payouts. The most common launch mistake is building saved cards before building webhook signature verification.
-
How long does payment gateway development take?
Stripe/PSP integration: 6–10 weeks to production-ready MVP. Custom orchestration on PSP infrastructure: 12–18 weeks. Full custom gateway from scratch: 24–40 weeks. These timelines assume a dedicated team and all third-party API access established before development begins. The biggest timeline risk in payment development is not engineering complexity; it is waiting for production API access from acquirers, card networks, or fraud score providers after development is complete.
-
What is the best tech stack for a payment gateway?
For the transaction API: Node.js (NestJS) for high-concurrency payment request handling, or Python (FastAPI) if ML-based fraud scoring is a core component. For the database: PostgreSQL, ACID compliance is non-negotiable for financial data. Redis handles rate limiting, idempotency key deduplication, and session management. AWS provides PCI-DSS-compliant infrastructure with WAF, KMS key management, and RDS. For the merchant dashboard: React JS. For mobile payments: React Native. The data layer decision matters more than the language: integer monetary storage and double-entry bookkeeping are architecture requirements, not preferences.
-
What is the difference between a payment gateway and Stripe?
Stripe is a Payment Service Provider (PSP) that bundles a payment gateway, a payment processor, and a merchant account management service into one API. A standalone payment gateway handles only the data capture, encryption, routing, and authorization steps; it still requires a separate payment processor and acquiring bank. Building a custom gateway means building the gateway layer only, not replacing Stripe entirely; you still need to acquire bank relationships and card network connectivity. Most products should use Stripe as their payment gateway and processor; only build custom when GMV exceeds $50M–$100M/year or when you are building a gateway product itself.
-
Can I build a payment gateway with an India-based development team?
Yes. The compliance obligations sit with the licensed merchant or payment aggregator in the operating jurisdiction, not the development partner. Acquaint Softtech delivers payment gateway builds for clients in the US, UK, Australia, and UAE from India, operating under each client's compliance framework. The standard protections are an NDA signed before the first call, a Data Processing Agreement covering any PII in scope, clear IP ownership (client owns all code from day one), and a security-vetted development environment. The first developer deploys within 48 hours of engagement confirmation.
-
What is PCI-DSS, and how does it apply to payment gateway development?
PCI-DSS (Payment Card Industry Data Security Standard) is the security framework that governs any system that processes, transmits, or stores cardholder data. Using Stripe Hosted Fields or Elements reduces your scope to SAQ A, the lowest tier, requiring only a self-assessment questionnaire. Building custom card capture forms expands the scope to SAQ C or SAQ D. Building a full custom card vault requires Level 1 compliance, an annual on-site audit by a Qualified Security Assessor (QSA) costing $15,000–$50,000. The architecture decision of where card data first enters your system is the PCI-DSS scope decision, and it must be made before the first line of code is written.
I help agencies and founders scale their tech teams with the right developers at the right time. At Acquaint Softtech, I focus on building long term partnerships and making remote hiring simple, predictable, and results driven. My goal is straightforward to help businesses grow faster with reliable dedicated developers.
Table of Contents
Get Started with Acquaint Softtech
- 13+ Years Delivering Software Excellence
- 1300+ Projects Delivered With Precision
- Official Laravel & Laravel News Partner
- Official Statamic Partner
Related Blog
.webp "The Complete Guide to FinTech Software Development in 2026")
The Complete Guide to FinTech Software Development in 2026
Complete guide to fintech software development 2026: all five verticals, compliance architecture, real build sequences, AI capabilities, and fintech development cost, from 1,300+ delivered projects.
Acquaint Softtech
May 6, 2026
Laravel 12 for SaaS & Fintech: Scalable, Secure, Compliant
Explore how Laravel 12 powers SaaS, fintech, and regulated industry apps with compliance, modularity, and secure architecture.
Acquaint Softtech
July 1, 2025
MCP vs. MLP vs. MVP: Right Launch Strategy for a Fintech SaaS in 2026
How do you choose MCP, MLP, or MVP for your US fintech SaaS in 2026? Learn which launch strategy saves time, cuts costs, and drives real growth.
Acquaint Softtech
April 7, 2026India (Head Office)
203/204, Shapath-II, Near Silver Leaf Hotel, Opp. Rajpath Club, SG Highway, Ahmedabad-380054, Gujarat
USA
7838 Camino Cielo St, Highland, CA 92346
UK
The Powerhouse, 21 Woodthorpe Road, Ashford, England, TW15 2RP
New Zealand
42 Exler Place, Avondale, Auckland 0600, New Zealand
Canada
141 Skyview Bay NE , Calgary, Alberta, T3N 2K6