HIPAA compliant payment processing in health apps 2026: Stripe vs IAP
TL;DR
HIPAA compliant payment processing in a healthcare app in 2026 comes down to one rule: the card goes to a PCI Level 1 processor, the clinical context stays in your database, and the two meet only through a token. The channel depends on what you sell. A doctor's time can be billed by card on both stores. App features sold to one user go through Apple and Google billing.
- Apple guideline 3.1.3(d) lets real-time medical consultations between two people skip in-app purchase.
- Google Play says regulated clinical services should not use Play billing at all.
- A $50 monthly plan costs $2.10 in Stripe fees and $15 through Apple in its first year.
- Raw card numbers on your servers can mean more than 300 PCI DSS controls instead of the short SAQ A.
Two rulebooks meet at the checkout
A telemedicine payment touches two regimes. PCI DSS protects the card. HIPAA protects the patient. Most payment bugs in health apps come from treating one as if it covered the other.
HIPAA reaches further into billing than people expect. The HHS summary of the Privacy Rule counts information about "the past, present, or future payment for the provision of health care to the individual" as individually identifiable health information. For a covered entity, the invoice that says a patient paid for a psychiatry visit is PHI.
The processor sits outside that. The HHS business associate FAQ says no business associate agreement is needed when a financial institution processes "consumer-conducted financial transactions by debit, credit, or other payment card" for health care. The exemption covers moving money. Send the processor a diagnosis and you have handed PHI to a party that never signed for it.
What changed in the payment rules by October 2026
Four dates moved the arithmetic.
On March 31, 2025, PCI DSS v4.0.1 payment page requirements 6.4.3 and 11.6.1 took effect. The PCI Security Standards Council removed both from SAQ A and added an eligibility check: merchants must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."
On June 30, 2026, Google split its fee in the US, the UK and the EEA. Per Google's announcement, auto-renewing subscriptions carry a 10% service fee, and Google Play billing adds a 5% billing fee. On October 1, 2026, US developers in Google's alternative billing and external links programs began reporting transactions and paying service fees.
US App Store apps may already link to web checkout. On August 14, 2026, Apple asked the court to approve 15% on linked purchases, 10% on renewals and 5% for small businesses, iClarified reported. Until the district court rules, Apple collects no commission on US link-outs, as Frankfurt Kurnit notes.
How we compared the payment architectures
We read the first-party rules for each channel: Apple's guidelines and subscription pages, Google's Payments policy and fee announcement, the PCI Council's SAQ A notice, HHS guidance, and the pricing pages of Stripe and RevenueCat. Fees assume a $50 monthly membership, the US storefront and a US domestic card, before tax. We did not test App Review, which decides edge cases one app at a time.
Payment architectures at a glance
| Architecture | What it bills | Store rule | PCI scope |
|---|---|---|---|
| Card through the processor's SDK | One-to-one consultations, care plans | Apple 3.1.3(d), Google clinical services exclusion | SAQ A |
| Apple in-app purchase | Digital features, content, group sessions | Apple 3.1.1 | None for you |
| Google Play billing | Digital subscriptions | Google Payments policy | None for you |
| US web link-out | Digital subscriptions sold on the web | Apple 3.1.1(a), Google US programs | SAQ A on your checkout |
| Stripe Connect marketplace | Patient pays, doctor gets paid | Same as card | SAQ A for the platform |
Where the PCI and HIPAA boundary sits
Draw the boundary one data element at a time.
| Data | Where it lives | Rulebook |
|---|---|---|
| Card number and CVC | The processor only, entered in its SDK or hosted page | PCI DSS |
| Token, card brand, last four digits, expiry | Your database | Out of PCI scope, per Stripe |
| Visit reason, diagnosis, specialty, prescription | Your PHI store only | HIPAA |
| Invoice, plan name, the fact of paying for care | Your PHI store; the processor sees an amount and an ID | HIPAA |
| Store receipt and entitlement state | An entitlement service keyed by internal user ID | Store terms, then HIPAA |
Stripe's integration security guide covers the first two rows. Card type, last four digits and expiry are "not subject to PCI compliance," while a business handling untokenized card numbers "might be required to meet more than 300 security controls in PCI DSS."
The HIPAA leaks are smaller. A product ID such as adhd_monthly tells Apple, Google and every analytics tool what the patient is treated for. So does a charge description, a statement descriptor or a receipt email that names the service. Stripe's metadata docs warn never to store sensitive information there and show the fix: keep the data in your own database and store only its ID. Apply that to every field that leaves your system.
When Apple and Google require in-app purchase
Guideline 3.1.1 of the App Store Review Guidelines says features and content sold inside the app, subscriptions included, use in-app purchase. Guideline 3.1.3(d) then allows other payment methods for "real-time person-to-person services between two individuals (for example tutoring students, medical consultations, real estate tours, or fitness training)." One-to-few and one-to-many services must use in-app purchase, so a live group therapy session goes through Apple. Under 3.1.3(e), goods and services consumed outside the app, such as a lab kit or a shipped prescription, must not use in-app purchase.
Google is clearer. Its Payments policy page states that "transactions involving regulated clinical services should not use Google Play's billing system," naming a doctor consultation and a prescription. One-to-one health coaching is exempt if the session cannot be replayed in a Play app. A wellness content subscription still requires Play billing.
The Android side of these rules sits in the Google Play health content and services policy.
Patient subscriptions for telemedicine
The hard case is the bundle: monthly visits plus a content library plus symptom tracking. Neither store has a rule for that mix. A developer asked Apple's forum this exact question about a telehealth plan with 1-on-1 video visits, and the thread has no answer.
So make the answer obvious in the product. If the plan is a clinical relationship, with a licensed clinician on the other end and features that support that care, bill it by card and say so in the review notes. If a tier is mainly digital, sell it through in-app purchase. Apple's subscription page pays 70% in a subscriber's first year and 85% after one year of paid service. The Small Business Program pays 85% from the start below 1 million USD in proceeds.
In code, one entitlement service decides what a patient can open and reads from every billing source.
Doctor subscriptions and payouts
Guideline 3.1.3(c) lets an app sold to organizations give staff access to subscriptions bought elsewhere, and says "consumer, single user, or family sales must use in-app purchase." A clinic buying seats fits the first part. A solo doctor buying a membership in the iOS app fits the second. On Google Play, a doctor's membership counts as a subscription service, so Play billing or US alternative billing applies.
We have seen telemedicine marketplace briefs ask for physician memberships through in-app purchase from the first release. That works for solo doctors. Group practices then sign a contract and pay an invoice outside both stores.
Paying doctors for visits runs on a marketplace product. Stripe Connect charges $2 per monthly active account and 0.25% + 25 cents per payout when the platform handles pricing. A weekly $1,000 payout costs $2.75.
Who should own the developer account that receives these payments is covered in our guide to App Store approval for healthcare apps.
What each architecture costs on a $50 membership
| Channel | Fee | You keep |
|---|---|---|
| Stripe card, 2.9% + 30 cents, plus Stripe Billing at 0.7% | $2.10 | $47.90 |
| Apple in-app purchase, first year | $15.00 | $35.00 |
| Apple, after one year or in the Small Business Program | $7.50 | $42.50 |
| Google Play billing, 10% service plus 5% billing | $7.50 | $42.50 |
| Google US alternative billing with Stripe | $7.10 | $42.90 |
| Apple US link-out with Stripe, if the proposed 15% is approved | $9.60 | $40.40 |
The 10% on subscriptions under US alternative billing is set on Google's program page, the same rate as on the first $1M of annual earnings. Card rates come from Stripe's pricing page. Selling through both stores and the web adds a subscription layer: RevenueCat is free up to $2,500 in monthly tracked revenue, then 1%, so $0.50 here.
Then count the engineering. Google's notification reference says a notification tells you "only that the purchase state changed," so the backend calls the Play Developer API and deduplicates by message ID. Stripe webhooks need signature checks. We have audited a care product billing through Stripe, StoreKit, Google Play and RevenueCat at once; the gaps that blocked feature work sat in webhook handling and the shared entitlement record.
Which architecture fits your product
- One-to-one video visits: card through the processor's mobile SDK, on both stores.
- A care plan with a clinician on the other end: card subscription on Stripe Billing.
- A program or content library with no clinician: in-app purchase and Play billing.
- Live group classes or group therapy: in-app purchase.
- Solo doctors buying memberships: in-app purchase, with Stripe Connect for payouts.
- Clinics buying seats: contract and invoice, with the app as a login.
- Lab kits, devices or shipped medication: card only.
Our telemedicine app development guide covers the rest of the build, and our patient portal ranking covers bill pay inside a portal.
What our published case studies show about payments
We reviewed every case study Mercury Development publishes for apps that take money from users. Around 10% do, and each used a different channel.
The Grant's phone and tablet app has payment gateway integration built for client-side PCI compliance. GreenLinks, a React Native golf app with cash prize challenges, got a wallet for payments and payouts. Hit It Great, a golf fitness app for iOS and Android, supports three subscription types: App Store, Google Play and Shopify.
None is a healthcare product. The pattern carries over anyway: the channel followed what was sold, and the app selling through three channels needed one place to answer whether a user is subscribed. We deliver PCI DSS compliant payment flows and build to HIPAA requirements; in a health app that answer comes from the PHI side of the boundary.
Our view: bill for the clinician, not for the app
Most teams start with the processor. Start with the product sentence. If a patient pays for time with a licensed clinician, both stores let you bill by card, PCI scope stays at SAQ A, and fees stay near 4%. If a patient pays for a library, a program or a tracker, that is a digital product, and fighting in-app purchase costs more in review cycles than the commission.
Then build the entitlement service before the paywall. It is the one component that knows who paid and what they are treated for, so it belongs inside your HIPAA boundary. Processors, stores and analytics should see an ID and an amount, nothing that reads like a chart.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The review of payment integrations in Mercury's published case studies belongs to the architecture and integration decisions his practice is responsible for.
Send your billing model and get the payment boundary drawn
Tell us what patients pay for, what doctors pay for, and which stores you ship to. We will mark which payments can run by card, which need store billing, where the PHI boundary sits, and what the entitlement service has to know.