How to Get a Google Places API Key (Step-by-Step)
TL;DR
Getting a Google Places API key takes six steps: create a Google Cloud project, enable billing (a credit card is required even for the free tier), enable the Places API, create the key, restrict it by app and API, and set quotas plus budget alerts. The key is free to create; restriction and quotas are what protect you from a surprise bill.
How to Get a Google Places API Key (Step-by-Step)
Getting a Google Places API key takes about five minutes, and this guide walks you through every step. But here is the part most tutorials rush past, and the part that actually matters: creating the key is easy, and restricting it is what saves you from a surprise bill. An unrestricted key that leaks can be used by anyone, and the charges land on you. So we will get your key first, then lock it down properly.
One thing to know up front, because it catches everyone: Google requires you to enable billing and add a credit card, even if you only plan to use the free tier. The key itself is free to create, and Google will not charge you unless you exceed the generous free limits, but the card is mandatory. This guide covers the full setup, how to secure the key, and how to make sure you never pay more than you meant to.
The quick answer: the six steps
If you just want the path, here it is. Each step is detailed below.
Create a Google Cloud project at the Google Cloud Console. Enable billing (a credit card is required, even for the free tier). Enable the Places API for your project. Create the API key under Credentials. Restrict the key immediately by app and by API. Set quotas and budget alerts so you never overspend.
The whole thing takes a few minutes. The two steps people skip, restriction and quotas, are the two that protect your wallet, so do not skip them.
What a Google Places API key actually is
A quick definition, so the steps make sense.
The Google Places API is a service that lets your website or app use Google's location data, searching for places, autocompleting addresses as a user types, and pulling details like a business's name, hours, or rating. An API key is a unique string of characters that identifies your project to Google every time your app makes one of these requests. It is both your pass to use the service and the way Google tracks your usage for billing.
Think of the key like a membership card with your name on it. It lets you in, and everything you do is charged to your account. That is exactly why keeping it private and restricted matters so much, which we will cover after the setup.
Step 1: Create a Google Cloud project
Go to the Google Cloud Console at console.cloud.google.com and sign in with a normal Google account. At the top of the page, click the project dropdown, then New Project. Give it a clear name (something like "my-app-places") and click Create.
If you are new to Google Cloud, you will also be offered a $300 free trial credit that lasts 90 days. This is separate from the Places API free tier and applies across Google Cloud, so it is a useful cushion while you get set up.
Step 2: Enable billing
This is the step that surprises people. Before you can use the Places API, you must enable billing on your project, which means adding a credit card, even if you intend to stay entirely within the free tier.
In the console menu, go to Billing, then link or create a billing account and add your card. Google will not charge you unless your usage goes past the free monthly limits, but it will not let you use the API at all without a card on file. This is normal and required for everyone.
Step 3: Enable the Places API
Now turn on the specific service you need. In the console menu, go to APIs & Services, then Library. Search for "Places API," select it, and click Enable.
Only enable the APIs you actually plan to use. Each one is billed separately, so enabling extras you do not need just widens the surface where costs, or mistakes, could appear.
Step 4: Create your API key
With the Places API enabled, go to APIs & Services, then Credentials. Click Create Credentials at the top, and choose API key. Google generates your key instantly and shows it in a dialog.
Copy the key somewhere safe. This is the string your app will use to make requests. Do not paste it into public code, a public repository, or anywhere it can be seen, for reasons the next step makes clear.
Step 5: Restrict your key (the step that protects you)
This is the most important step in the whole guide, and the one most tutorials treat as optional. It is not optional. An unrestricted key is a key anyone can steal and use, running up charges billed to you.
Restrict it in two ways. First, application restrictions: tell Google which websites, apps, or IP addresses are allowed to use this key, so a stolen key will not work from anywhere else. For a website, restrict it to your domain. Second, API restrictions: limit the key to only the Places API, so even if it leaks, it cannot be used for other, pricier Google services.
On the key's settings page in Credentials, set both restrictions and save. A properly restricted key is nearly useless to anyone who steals it, which is exactly what you want.
Step 6: Set quotas and budget alerts
The final safety layer. Restriction stops misuse; quotas and alerts stop overspending.
Set a quota limit on your Places API usage, ideally at or below the free monthly allowance, so requests simply stop once you hit your ceiling rather than rolling into paid usage. Quotas are the control that actually prevents charges. Then set a budget alert so Google emails you when spending approaches a limit you choose. Note the difference: a budget alert only warns you, while a quota actually caps usage. Use both, but rely on the quota to protect the bill.
What the Google Places API costs in 2026
A quick, honest picture so there are no surprises.
Google Places uses pay-as-you-go pricing, billed per SKU, meaning each type of request- a search, an autocomplete, a place-details lookup- has its own price. There is a free monthly allowance for each, and you only pay once you exceed it. As rough 2026 figures, a text search runs a few dollars per 1,000 requests, and a place-details call runs higher, in the range of several dollars to around $17 per 1,000 depending on how much data you request.
One counterintuitive thing worth knowing: with autocomplete, an abandoned search where the user types and then leaves can sometimes cost more than a completed one, because each keystroke can trigger a billable request. This is exactly why the quotas in Step 6 matter. Always check Google's official pricing page for current, exact numbers before you launch, since these change.
Common problems, and how to fix them
A few issues catch almost everyone. Here is how to clear them fast.
"This API key is not authorized." Your key restrictions are blocking the request. Check that your app's domain or IP is in the allowed list, and that the Places API is among the key's allowed APIs.
"Billing not enabled." You skipped or did not finish Step 2. Add a valid credit card to the billing account, even for free-tier use.
The key works locally but not in production. Your application restrictions likely allow your test environment but not your live domain. Add the production domain to the allowed list.
Unexpected charges. Almost always an unrestricted key that leaked, or missing quotas. Restrict the key immediately and set a quota below the free allowance.
Ready to build with Google's location data?
Getting a Google Places API key is quick, but doing it safely- restricting the key and capping usage- is what separates a smooth launch from a surprise invoice. Follow the six steps above, and you get a working key that stays secure and stays within budget.
If you would rather have the setup, integration, and cost controls handled properly as part of a real product build, the Craxinno team implements Google Maps and Places integrations for clients regularly. See recent work in the Craxinno portfolio, view our full stack on the technologies page, or email sales@craxinno.com.
Frequently Asked Questions
How do I get a Google Places API key?+
Create a project in the Google Cloud Console, enable billing by adding a credit card, enable the Places API from the API Library, then go to APIs & Services and Credentials, click Create Credentials, and choose API key. Google generates the key instantly. After creating it, restrict the key by application and API, and set quotas so you do not exceed the free tier.
Is the Google Places API key free?+
The key itself is free to create, and Google offers a free monthly allowance for Places API usage, so many small projects pay nothing. However, Google requires you to enable billing and add a credit card even for free-tier use. You are only charged once you exceed the free limits, and setting a quota below that allowance prevents charges entirely.
Why does Google require a credit card for a free API key?+
Google requires billing to be enabled on every project that uses the Places API, even if you stay within the free tier, so it can verify your account and bill any usage that exceeds the free limits. The card is mandatory to activate the API, but you will not be charged unless you go past the free monthly allowance, which you can prevent with quotas.
How do I stop my Google Places API key from being misused?+
Restrict the key in two ways. Set application restrictions so only your specific website, app, or IP addresses can use it, and set API restrictions so the key works only with the Places API. A restricted key is nearly useless to anyone who steals it. Also set a usage quota so that even authorized use cannot run up an unexpected bill.
How much does the Google Places API cost?+
Google Places uses pay-as-you-go pricing billed per request type, with a free monthly allowance for each. Beyond the free tier, a text search costs a few dollars per 1,000 requests and a place-details call costs more, up to around $17 per 1,000 depending on the data requested. Note that abandoned autocomplete sessions can also incur charges, so always check Google's current pricing page before launching.
Need a site that performs?
Fast, accessible web apps in React and Next.js — built to rank and built to scale.
Start a projectKeep ReadingMore case studies like this
Engineering retros, product launches, and brand systems from our studio — updated monthly.
All case studiesTechnology Used
.svg){kind=logo}
Node.js
JavaScript
Next.js
ReactTags & Keywords
Continue with Blogs.
View all blogs
StripeHow to Add Stripe Payments to a Next.js App
How to Add Stripe Payments to a Next.js App Adding Stripe payments to a Next.js app takes about 30 minutes with the modern approach, and it is simpler than most tutorials make it look. The trick is to use Stripe Checkout , Stripe’s own hosted payment page, rather than building your own card form. You create a checkout session on the server, redirect the user to Stripe to pay, and Stripe sends you back. You never handle raw card details, which makes it faster to build and far more secure. This guide walks through the whole thing, step by step, for the Next.js App Router. Here is the one principle that matters more than any line of code, and the thing beginners get wrong: never trust the browser to confirm a payment. A user can close the tab, lose connection, or tamper with the page after paying. The only reliable way to know a payment succeeded is a webhook, a message Stripe sends directly to your server. Getting the webhook right is what separates a real integration from one that silently loses orders, so this guide treats it as essential, not optional. This guide covers setup, the checkout flow, the all-important webhook, testing, and going live. The quick answer: the whole flow If you want the shape of it first, here is what you are building. Install Stripe and add your API keys to environment variables. Create a server route that makes a Stripe Checkout session and returns its URL. Add a button that calls that route and redirects the user to Stripe to pay. Create a webhook route that listens for Stripe’s confirmation and fulfills the order (this is the critical part). Test locally with the Stripe CLI, then add your live keys and production webhook to go live. The golden rule throughout: Stripe Checkout handles the payment UI and card security for you, and the webhook, not the browser, is the source of truth for whether a payment actually happened. Prerequisites Get these in place first. A Next.js app using the App Router (Next.js 13 or newer), and Node.js 18 or newer. A Stripe account (free to create), with access to your API keys in the Stripe Dashboard. You will use test keys while building. Basic familiarity with Next.js API routes (route handlers) and environment variables. Step 1: Install Stripe and set up your keys Install the Stripe packages: npm install stripe @stripe/stripe-js Then add your keys to a .env.local file in your project root (use your test keys while building): STRIPE_SECRET_KEY=sk_test_your_key NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_your_key STRIPE_WEBHOOK_SECRET=whsec_your_secret NEXT_PUBLIC_APP_URL= http://localhost:3000 Add .env.local to your .gitignore so your secret keys never reach your repository. The secret key must stay on the server only; the publishable key (prefixed NEXT_PUBLIC_) is safe in the browser. It also helps to create one shared Stripe client. Make a file at lib/stripe.ts: import Stripe from “stripe”; export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!); Now every route can import the same configured client. Step 2: Create the checkout session route This server route creates a Stripe Checkout session and returns its URL. Create app/api/checkout/route.ts: import { NextResponse } from “next/server”; import { stripe } from “@/lib/stripe”; export async function POST() { const session = await stripe.checkout.sessions.create({ mode: “payment”, line_items: [ { price_data: { currency: “usd”, product_data: { name: “Your Product” }, unit_amount: 2000, // $20.00, in cents }, quantity: 1, }, ], success_url: ${process.env.NEXT_PUBLIC_APP_URL}/success , cancel_url: ${process.env.NEXT_PUBLIC_APP_URL}/cancel , }); return NextResponse.json({ url: session.url }); } A few notes: amounts are in the smallest currency unit (cents), mode is “payment” for a one-time purchase (use “subscription” for recurring), and success_url and cancel_url are where Stripe sends the user after. The route returns session.url, the hosted Stripe page you will redirect to next. Step 3: Add the checkout button On your page, add a button that calls the route and redirects the user to Stripe. In a client component: “use client”; export default function CheckoutButton() { async function handleClick() { const res = await fetch(“/api/checkout”, { method: “POST” }); const data = await res.json(); window.location.href = data.url; // redirect to Stripe } return <button onClick={handleClick}>Buy now</button>; } That is the entire customer-facing flow: the user clicks, your route makes a session, and the browser sends them to Stripe’s secure page to enter card details. You never touch the card data. Step 4: Create the webhook (the critical part) This is the step that makes the integration trustworthy. After a payment, Stripe sends a message to your server confirming it. You listen for that message and fulfill the order, send the product, mark it paid, email the receipt. Create app/api/webhooks/stripe/route.ts: import { NextResponse } from “next/server”; import { headers } from “next/headers”; import { stripe } from “@/lib/stripe”; import Stripe from “stripe”; export async function POST(req: Request) { const body = await req.text(); // CRITICAL: raw text, not JSON const signature = (await headers()).get(“stripe-signature”)!; let event: Stripe.Event; try { event = stripe.webhooks.constructEvent( body, signature, process.env.STRIPE_WEBHOOK_SECRET! ); } catch (err) { return new NextResponse(“Invalid signature”, { status: 400 }); } if (event.type === “checkout.session.completed”) { const session = event.data.object as Stripe.Checkout.Session; // Fulfill the order here: mark paid, send the product, email receipt console.log(“Payment confirmed:”, session.id); } return NextResponse.json({ received: true }); } Two things catch almost everyone here. First, you must read the raw request body with req.text(), not parsed JSON, because Stripe verifies a signature against the exact raw bytes. Second, always return a 200 response, even for events you do not handle, otherwise Stripe retries for up to 72 hours. Verifying the signature is what proves the message genuinely came from Stripe and not an attacker. Step 5: Test locally with the Stripe CLI You cannot test webhooks just by clicking around, you need Stripe to reach your local server. The Stripe CLI does this. Install it, log in, then forward events to your app: stripe listen --forward-to localhost:3000/api/webhooks/stripe This prints a webhook signing secret (starting whsec_), put that in your STRIPE_WEBHOOK_SECRET. Now run a test payment through your checkout button using Stripe’s test card number, 4242 4242 4242 4242 with any future expiry and any CVC, and watch the CLI forward the checkout.session.completed event to your webhook. When your webhook logs the confirmation, the full loop works. Step 6: Go live Switching to real payments is a short checklist. Replace your test API keys with your live keys (from the Stripe Dashboard, after activating your account). In the Stripe Dashboard, under Developers then Webhooks, add your production webhook endpoint, https://your-domain.com/api/webhooks/stripe , and copy its signing secret into your production environment variables. Deploy, and run one real, small transaction to confirm the live flow end to end. On Vercel or similar, add all your environment variables in the project settings. That is it: real payments flowing, confirmed by webhook, with card security handled entirely by Stripe. The mistakes that break Stripe integrations A few errors catch almost everyone. Avoid these. Trusting the browser instead of the webhook. If you mark an order paid based on the user landing on your success page, you will lose orders and let people fake payments. The webhook is the only source of truth. This is the single most important rule. Parsing the webhook body as JSON. Reading the body any way other than raw text breaks signature verification. Use req.text(). Exposing the secret key. The secret key must stay server-side only. Never prefix it with NEXT_PUBLIC_ or use it in a client component. Not returning 200 from the webhook. If your handler errors or returns a non-200, Stripe retries for up to 72 hours. Handle events, then return 200. Forgetting the production webhook. Local testing uses the CLI; production needs a webhook endpoint registered in the Stripe Dashboard with its own signing secret. Forgetting this means payments work but orders never get fulfilled live. Ready to add payments to your app? Adding Stripe to a Next.js app is genuinely approachable: hosted Checkout handles the hard, sensitive parts, and a correct webhook makes it reliable. Get those two right, and you have production-grade payments without ever touching raw card data. When you want payments built properly, including subscriptions , multiple gateways, or complex billing, as part of a real product, the Craxinno team integrates Stripe and other payment gateways into Next.js and mobile apps. See recent work in the Craxinno portfolio, explore our custom software development service , or email sales@craxinno.com .
AI ChatbotHow to Add AI Chat to Your Website (Step-by-Step)
How to Add AI Chat to Your Website (Step-by-Step) Adding AI chat to your website is far easier in 2026 than most business owners expect, and there are three ways to do it, from a no-code tool you can set up in an afternoon to a fully custom assistant trained on your own content. The right path depends on one thing: how much you need the chat to actually know about your business. This guide walks through all three, step by step, so you can pick the one that fits and get it live. Here is the key decision to make first, because it saves you time and money. A generic chat widget that answers from a script is cheap and fast but limited. An AI chat that answers accurately from your own content, your products, policies, and FAQs, is more powerful and is what most businesses actually want, and it is now very achievable. Knowing which you need before you start is the difference between a quick win and a frustrating one. This guide covers the three ways to add AI chat, a step-by-step for each, what it costs, and how to choose. The quick answer: three ways to add AI chat If you want the options at a glance, here they are, from easiest to most powerful. A no-code chat tool (easiest). Sign up for a service like a hosted AI chat widget, paste a snippet of code into your site, and you have AI chat live in an afternoon. Best for simple needs and non-technical teams. A platform with your own content (middle). Use an AI chat platform that lets you upload your documents, website pages, or FAQs, so the chat answers accurately from your actual business content. Still mostly no-code, more useful, modest monthly cost. A custom AI chat (most powerful). Have a developer build a chat assistant trained on your content, connected to your systems (orders, bookings, accounts), that matches your brand and can actually take actions. Best when chat is important to your business and you want full control. The honest rule: start with the simplest option that meets your need. Most businesses are well served by option two, a platform that answers from their own content, without the cost of a custom build. First, decide what you actually need Before choosing a method, answer two quick questions, because they determine which path fits. Does the chat need to know your business? If you just want to greet visitors and answer a few generic questions, a basic widget is fine. If you want it to answer accurately about your products, pricing, policies, or services, you need a method that uses your own content, which rules out the most basic widgets. This is the single most important question. Does the chat need to do things, or just answer? If answering questions is enough, a platform works. If you need the chat to take actions, look up an order, book an appointment, update an account, you are moving toward a custom build, because that requires connecting to your systems. Most businesses start with answering and add actions later. Your answers point you straight to one of the three methods below. Method 1: Add a no-code AI chat widget (the fast path) This is the quickest way to get AI chat live, and it needs no developer. Here is the process. Step 1: Choose a tool. Pick a hosted AI chat service. Many exist, offering a chat widget you can add to any website, often with a free tier to start. Step 2: Sign up and configure. Create an account, set the chat's name, greeting, and tone, and choose basic settings like colors to match your brand. Step 3: Add your knowledge (if supported). Better no-code tools let you paste in FAQs or point the tool at your website so it can answer from your content. Do this if available, it is what makes the chat actually useful. Step 4: Copy the code snippet. The tool gives you a small snippet of code (usually one line). Step 5: Paste it into your website. Add the snippet to your site, in your site builder's "custom code" or "footer" section, or, on WordPress, via a plugin or the theme footer. Save, and the chat appears on your site. Step 6: Test it. Open your site, ask the chat a few real questions, and refine its settings or knowledge based on how it answers. That is it, AI chat live, often within an afternoon. The limit is that no-code tools offer less control and cannot deeply connect to your systems. Method 2: Use a platform trained on your content (the sweet spot) This is where most businesses should land. These platforms are still largely no-code, but they let the chat answer accurately from your own business content, which is what makes AI chat genuinely useful. Step 1: Choose a content-aware AI chat platform. Pick a service built to ingest your documents and website and answer from them (this uses a technique called RAG , which grounds answers in your real content so the chat does not make things up). Step 2: Upload your content. Add your FAQs, product and service pages, policies, and any help documents. The platform processes them so the chat can retrieve the right answer. Step 3: Configure behavior and brand. Set the tone, the greeting, what to do when it does not know (for example, offer to connect to a human), and match your brand. Step 4: Add it to your site. As with method one, paste the provided snippet into your website. Step 5: Test with real questions, then refine. Ask the questions your customers actually ask, see where answers fall short, and improve the content you fed it. The quality of your uploaded content largely determines how good the chat is. This path gives you a chat that answers accurately about your business, usually for a modest monthly fee, without a custom build. For most businesses, it is the best balance of power and effort. Method 3: Build a custom AI chat (the powerful path) When AI chat is important to your business, when you need it to match your brand exactly, answer from your full knowledge, and take real actions, a custom build is the answer. This needs a developer, but it gives you complete control. A custom AI chat typically uses an LLM (like Claude or GPT) connected to your content through RAG, so it answers accurately from your data, and connected to your systems so it can act, look up an order, check availability, update a record. It lives on your site exactly as you design it, with no third-party branding, and you own it. The build process, at a high level: define what the chat should do and answer, connect it to your content and systems, engineer and test its behavior against real questions, and deploy it to your site with a clean handoff to a human when needed. This is real development, and it is what our guide on the cost to build an AI chatbot breaks down in detail, and if the chat needs to complete tasks rather than just answer, that moves into agent territory, which our guide on AI agents vs chatbots explains. Choose this when chat is a core part of your customer experience and the simpler options have hit their limits. What it costs A quick, honest picture so you can budget. No-code widget: often free to start, then roughly $20 to $100 a month for a small business as you add features and volume. Content-aware platform: typically $50 to a few hundred dollars a month, depending on volume and features. The sweet spot for most businesses. Custom build: a one-time development cost (plus ongoing model usage and maintenance), which starts in the low five figures and scales with complexity. Right when chat is important enough to justify owning it. The pattern: the more the chat needs to know and do, and the more control you want, the more it costs, so match the spend to how much the chat matters to your business. How to choose your method A simple way to decide. If you want AI chat live fast, for simple questions, and have no developer, use a no-code widget (method one). If you want the chat to answer accurately about your business without a custom build, which is most businesses, use a content-aware platform (method two). If chat is core to your business and you need full control, brand match, and the ability to take actions, build custom (method three). And the smart sequence: start simple, prove chat helps your visitors, learn what they actually ask, then upgrade to a more powerful method if the value is there. There is no need to build custom on day one, and often no need to build custom at all. Ready to add AI chat to your website? Adding AI chat is one of the highest-return, lowest-friction ways to improve your website in 2026, it answers visitors instantly, around the clock, and captures leads you would otherwise lose. Start with the simplest method that meets your need, ground it in your real content, and upgrade only when the value justifies it. When you need AI chat that truly fits your business, trained on your content, connected to your systems, matched to your brand, the Craxinno team builds custom AI chat and assistants that work in production. See recent AI work in the Craxinno portfolio , explore our AI development service , or email sales@craxinno.com .
StripeStripe vs Razorpay: Which Payment Gateway to Use?
Stripe vs Razorpay: Which Payment Gateway to Use? Stripe vs Razorpay is less a head-to-head fight than a question of geography: where is your business registered, and where are your customers? Razorpay is built for India, dominating local payment methods like UPI, and is usually the better choice for Indian businesses serving Indian customers. Stripe is built for the world, excelling at international cards and global subscriptions, and is the better choice for cross-border and global businesses. They are not really competing for the same job, and knowing that clears up most of the decision. Here is the insight most comparisons miss, and the one that saves businesses the most money: for many companies, the answer is both. A common setup uses Razorpay to collect payments from Indian customers, where its UPI support and higher domestic success rates win, and Stripe to collect from international customers, where its global network and trust recognition win. So before you frame this as "which one," ask whether your business actually needs one, the other, or both. This guide covers what each gateway is, how they really differ, where each genuinely wins, and a simple way to choose for your business. The quick answer If you want the decision fast, use this. Choose Razorpay if your business is registered in India and your customers are mostly Indian. It supports all local payment methods (UPI, RuPay, net banking, wallets) with excellent success rates, charges around 2% plus GST on domestic cards and 0% on UPI, settles to your Indian bank quickly, and includes a business-banking suite (RazorpayX). For an India-first business, it is the natural default. Choose Stripe if your business is global, or you need to accept international cards and run complex subscriptions. Stripe leads on cross-border card payments, SaaS billing, and developer experience, and is trusted worldwide. Note that in India, Stripe is available only as a sales-gated preview, so availability depends on where your business is registered. Use both if you serve both Indian and international customers: Razorpay for domestic payments, Stripe for international. This is a common, sensible setup, not a compromise. The honest rule: let your business location and your customers' location decide. India-first points to Razorpay, global points to Stripe, and both-markets often points to running both. What Stripe and Razorpay actually are A quick definition of each, because they were built for different worlds. Razorpay is an Indian payment gateway built specifically for India's payments landscape. It handles all the local methods Indian customers actually use, UPI, RuPay cards, net banking, and wallets, with routing tuned for high success rates on Indian transactions. It has grown into a broader financial platform, adding business banking, payroll, and lending (RazorpayX). To use it, your business generally needs to be registered in India. Stripe is a global payment platform built for businesses operating across borders. It is known for a best-in-class developer experience, powerful subscription and billing tools, and support for card payments across many countries and currencies. It is the gateway behind a large share of global SaaS and online businesses. In India specifically, Stripe is offered only as a preview you reach through its sales team, so direct availability is limited. The core split: Razorpay is India-first, optimized for local methods and Indian businesses; Stripe is global-first, optimized for cross-border cards and international scale. That difference, more than any feature, decides which fits you. The differences that actually matter Five differences decide most real decisions. Here is the honest version of each. Where you can use it. This comes first because it can make the decision for you. Razorpay requires an India-registered business. Stripe signs up businesses directly in its many supported countries, but in India it is only a sales-gated preview. So your business's country of registration may rule one of them out before you compare anything else. Local payment methods (India). Razorpay wins decisively for Indian customers. It supports UPI (at 0% fee), RuPay, net banking, and wallets natively, with routing that delivers higher domestic success rates. Since UPI dominates Indian online payments, this is a major advantage for any business selling to Indian customers. Stripe's India method coverage is narrower. International payments. Stripe wins. For accepting cards from customers around the world and handling multiple currencies, Stripe's global network, higher international success rates, and worldwide trust make it the stronger choice. Razorpay does support international cards (around 3% plus GST) but is built primarily for the Indian market, and international settlement can involve extra approval steps. Subscriptions and billing. Stripe is the global gold standard for complex recurring billing, metered usage, and international subscriptions, making it the default for SaaS with global customers . Razorpay has strong subscription tools too, with deep support for Indian e-mandates, so for India-focused recurring billing it is excellent. Match this to where your subscribers are. Pricing. Broadly similar on standard domestic transactions (both around 2% plus GST on Indian cards), with the differences in the details: Razorpay charges 0% on UPI, a real saving for Indian businesses, while Stripe adds a surcharge on international cards plus a currency-conversion markup. The cheaper option depends on your payment mix, so model it against how your customers actually pay. Why many businesses use both Here is the part the "versus" framing misses, and the practical answer for a lot of companies. You do not have to pick one. If your business serves both Indian and international customers, a common and smart setup is Razorpay for domestic payments and Stripe for international. Indian customers pay via UPI and local cards through Razorpay, where success rates and fees are best for India; international customers pay by card through Stripe, where the global network and trust recognition win. You get the strengths of both, matched to each customer base. This is a mature, widely used architecture, not a hack, and it is especially common for Indian businesses with global ambitions, exporters, SaaS companies, and marketplaces selling across borders. The one cost is a bit more integration work to run two gateways, which is exactly the kind of thing worth getting right at build time rather than retrofitting later, since payment integration is one of the trickier parts of any build . When to choose Razorpay Razorpay is the right call in these common situations. Choose it when your business is registered in India and serves mainly Indian customers, since it supports all local methods with the best success rates. Choose it when UPI is important to your customers, because Razorpay's native, 0%-fee UPI support is a real advantage. Choose it when you want quick settlement to an Indian bank and a familiar, responsive India-based support team. And choose it when you want business banking, payroll, or lending alongside payments, via RazorpayX. For an India-first business, Razorpay is usually the practical winner. When to choose Stripe Stripe is the stronger choice when your business is global or cross-border. Choose it when you accept payments from customers around the world and need many currencies and high international success rates. Choose it when you run complex or international subscriptions, where Stripe's billing tools are the global standard. Choose it when developer experience and clean APIs matter to your team, since Stripe is known for them. And choose it when your business is registered in a country Stripe supports directly. For a global or SaaS business, Stripe is built for exactly that job. Ready to set up the right payment gateway? The Stripe versus Razorpay choice comes down to geography: where your business is registered and where your customers are. India-first points to Razorpay, global points to Stripe, and serving both markets often means running both. Getting the integration right, including handling both gateways cleanly if you need them, is what turns the right choice into reliable revenue. The Craxinno team integrates Stripe, Razorpay, and other payment gateways into web and mobile apps, including dual-gateway setups for businesses serving India and the world. See recent work in the Craxinno portfolio, explore our custom software development service, or email sales@craxinno.com .
© 2026 — Craxinno Technologies
