What it costs to add payments to an app

$19,000 – $27,000, 11–15 weeks, on an app people already use. That covers the payment itself and the screen your finance person needs to tie it back to the bank. Before you spend that, find out whether Apple and Google take a cut of what you sell, because that answer is worth more money than the build is.

$19,000 – $27,000: Payments on an app that already ships
2.9% + $0.30: Stripe’s published US online card rate, August 2026
15%: Apple’s Small Business Program rate, under $1 million a year

Written by

WhatWillMyAppCost

We build the estimator this site runs on, and we design and build custom mobile and web software for a living. Every figure below is the estimator’s own output, except the published vendor prices, which are read off each company’s own page and dated.

Your app works. People use it. They pay you by invoice or over the phone, somebody chases the ones who don’t, and every month a few of them slip. Taking the card inside the app looks like a small feature, and the part everybody pictures genuinely is one.

What it costs on an app that already ships, why the card form is the small half, whether the app stores take a percentage of what you sell, what the processor charges on top, what recurring billing adds, when PCI compliance comes into it, and what the same feature costs if the app doesn’t exist yet.

What does it cost to add payments to an app?

$19,000 – $27,000, and 11–15 weeks of calendar, assuming both stores already carry your app, the screens are drawn, and the system behind it has never handled money. That buys paying by card, a card saved so nobody retypes it, receipts, refunds, and a screen your finance person can use to tie the app to the bank statement.

$19,000 – $27,000: Payments and the reconciliation screen
$16,000 – $23,000: Taking the card and nothing behind it

Dropping the finance screen saves about $3,500, and it’s the saving people regret most. Somebody has to answer “did that one go through” every week for the rest of the app’s life, and without a screen the answer comes from an engineer looking at a database. Price it against your own app, because how much of your backend already exists moves this number more than anything else in it.

Why does taking a card cost that much?

Taking a payment is straightforward. Refunds, failures, disputes, receipts, retries, and the reconciliation that finance will eventually ask for are the actual work.

What you are picturing: “They tap pay, it charges the card.” That part is a day of work, and it behaves exactly the way you imagine it does.
What finance signs off on: The charge, plus the card declining, plus the card declining because the bank wants a code from a text message, plus the customer closing the app halfway through, plus the refund, plus the partial refund, plus the receipt, plus the dispute six weeks later, plus a record of every one of those that matches what the bank says happened.

The last one is where projects run long. A payment feature that works is easy to demo and hard to close out, because closing it out means somebody in finance agreeing that the numbers reconcile. Get that person into the conversation in week one. They ask different questions than anyone else on the project, and they ask them earlier than they’ll be asked otherwise.

Will Apple and Google take a cut?

It depends entirely on what you sell, and this is the single most valuable thing to settle before anybody writes any code.

Selling something used inside the app: Subscriptions, premium features, credits, unlocking content. Both stores require their own billing for these, so they process the payment and take their percentage.
Selling physical goods, or anything used outside the app: Apple’s guidelines go the other way. Physical goods and services consumed outside the app “must use purchase methods other than in-app purchase”, so you take the card yourself and the stores take nothing.
Selling one person’s time to one other person: Apple lists tutoring, medical consultations, real estate tours and fitness training here, and says you may use something other than in-app purchase. The catch that costs people money: one-to-few and one-to-many real-time services must still use in-app purchase. A class of eight is not two individuals.

When the stores are involved, Apple’s Small Business Program is 15% for developers whose proceeds, meaning sales after Apple’s own cut, were under $1 million in the prior calendar year and are still under it in this one. Above that Apple applies its standard rate, which it sets in the developer agreement instead of publishing on that page.

Google Play’s United States terms changed on June 30, 2026, and the rate turns on what you sell and when the person installed. Auto-renewing subscriptions are 10% plus a 5% billing fee. Everything else is that same rate on new installs, and 25% plus 5% on installs that predate the change. Selling credits or one-time unlocks to people who already have your app? The second number is the one to model. All of these were checked in August 2026 and all of them move, so read the current page before you plan around one.

A business selling real-world services pays a card processor about 2.9% where a store would have taken 15%. On $400,000 of app revenue that difference is roughly $48,000 a year, every year, against a build that happens once. Nothing else on this page moves that much money.

What does the card processor charge on top?

Stripe publishes 2.9% plus $0.30 per successful charge on domestic cards online in the US, as of August 2026. Disputes cost $15 each, and you get that back if you win.

What the rate does change is how you package what you sell. At 2.9% plus $0.30, a $5 charge loses 8.9% and a $200 charge loses 3.1%. If your app takes lots of small payments, batching them into one weekly or monthly charge is worth more than most of the build decisions below it.

These are list rates. Volume gets negotiated, and it is worth asking once you are processing steadily. Nothing about that changes the build.

What does recurring billing add?

About $3,000, taking the same app to $21,000 – $31,000. Recurring billing means entitlements, renewals, cancellations, grace periods, and on mobile, Apple and Google taking their own view of all of it.

$19,000 – $27,000: One-off payments
$21,000 – $31,000: Payments plus recurring billing

The work isn’t the renewal, it’s what happens around it. Somebody upgrades mid-month and expects the difference credited. A card expires and the customer keeps using the thing for three days while you retry. Somebody cancels and asks for the rest of the month. Every one of those is a rule your business decides, not an engineering choice, and deciding them late is what makes billing projects run long.

If a first release can survive on a single charge or a manual invoice, let it. The estimator defers recurring billing out of a first version for that reason, and a month of invoicing by hand tells you what your billing rules should be more cheaply than guessing them does.

Do you need PCI compliance?

Almost certainly not, and going out of your way to need it adds about $2,500 to the build plus an annual assessment that never goes away. Handling card data directly pulls your infrastructure into scope. Most projects should avoid this by never touching the card number.

The card number never touching your systems: The customer’s card details go straight from their phone to the processor, and your app only ever sees a token. This is how nearly every app should work, and it’s the $19,000 – $27,000 build above with nothing added.
The card number passing through your systems: Your servers, your logs, your backups and anything they touch come into scope for an annual assessment. That’s the version costing $2,500 more to build, and then costing again every year after that.

The situations that genuinely force it are narrow: a call center typing numbers off a phone call, a card reader you built yourself, or a contract that names it. If none of those describe you, build so the question never comes up.

What if the app doesn’t exist yet?

$23,000 – $35,000 for an app built from nothing with accounts and payments in it, on iPhone and Android. That’s more than adding payments to something that ships, and less than the two figures added together, because sign-in, screens, navigation and the API get paid for once.

$19,000 – $27,000: Adding it to an app that exists
$23,000 – $35,000: A new app with accounts and payments

Which is the argument for putting payments into the first release when you already know money is the point of the app. Coming back for them later means a second store submission and a second round of testing, and changes after launch get priced like the features they are. The logic runs the other way for anything you are less sure about, which what belongs in a first version covers.

Adding payments to an app that already ships costs $19,000 – $27,000 over 11–15 weeks. Recurring billing takes it to $21,000 – $31,000. Building from nothing with payments included is $23,000 – $35,000.

The percentages matter more than any of those. Selling something used inside the app means the stores take their share of every transaction for as long as the app exists. Selling physical goods, or anything used outside the app, means Apple’s own rules keep the stores out of it, and the 2.9% plus $0.30 you pay a processor is close to all of it. Which of those you are is not an engineering question, and it is the first one to settle.

FAQ

Questions about taking payments in an app

How much does it cost to add payments to an existing app?

$19,000 – $27,000, over 11–15 weeks, on an app people already use. It covers card payment, a saved card, receipts, refunds and a reconciliation screen. Without the reconciliation screen it’s $16,000 – $23,000, and that saving tends to get spent again later on somebody answering questions by hand.

What percentage do Apple and Google take from payments in an app?

It depends on what you sell, and for a lot of apps the answer is nothing. Apple’s published Small Business Program rate is 15% for developers whose proceeds were under $1 million in the prior calendar year; above that Apple applies a standard rate it sets in the developer agreement rather than on that page, so check your own agreement for the figure. Google Play in the United States is 10% plus a 5% billing fee on subscriptions, and 25% plus 5% on non-subscription sales to people who installed before June 30, 2026. Apps selling physical goods, or anything used outside the app, are required by Apple’s guidelines to use something other than in-app purchase, and the stores take nothing from those.

What does Stripe charge to process a payment?

2.9% plus $0.30 per successful domestic card charge online in the US, published on Stripe’s own pricing page and checked in August 2026. Disputes are $15 each and refunded if you win. Volume pricing is negotiable once you are processing steadily.

How much does it cost to add subscriptions to an app?

About $3,000 on top of one-off payments, taking a payments build on an existing app from $19,000 – $27,000 to $21,000 – $31,000. The cost is in the rules around the renewal: upgrades mid-cycle, expired cards, grace periods, cancellations and refunds. Those are business decisions before they are engineering ones, and deciding them late is what makes billing projects run over.

Do I need to be PCI compliant to take payments in my app?

Not if the card number never reaches your systems, which is how a modern payment integration works by default. Deliberately handling raw card data adds about $2,500 to a $19,000 – $27,000 payments build, plus an annual assessment that never goes away. Two situations genuinely force it: a call center where somebody types numbers off a phone call, and a contract that names it outright.

Can I use my own payment system instead of in-app purchase?

For physical goods and real-world services, Apple requires it. For digital content used inside the app, in-app purchase is the rule, though in the United States storefront Apple’s guidelines currently allow apps to include links and buttons pointing at an external purchase page without a special entitlement. That last part is specific to the US and has changed more than once, so check the current guidelines before you plan around it.

How long does it take to add payments to an app?

11–15 weeks to add payments and a reconciliation screen to an app that already ships. Add store review on top if you are going to the App Store and Google Play, and add whatever your finance team needs to sign off on reconciliation, which is the step most likely to be discovered late.

Is it cheaper to add payments now or later?

Now, if you already know money is the point of the app. A new build with accounts and payments in it is $23,000 – $35,000, and splitting it into two projects costs more, because the second one pays again for its own testing pass and its own store submission. If you’re still unsure whether people will pay at all, that ordering flips: a manual invoice for the first few months is the cheaper way to find out.