How to Accept Card Payments in a Mobile App for Goods and Services

In this guide, we at Talha Aslan and team walk through that flow from start to finish. It fits you best if you sell things people use in the real world, such as food orders, clothing, deliveries, cleaning, or rides. Here is the short roadmap:

1. Decide whether you sell physical goods and services or digital content.
2. Pick a payment provider or merchant account and finish the merchant agreement.
3. Add the provider's mobile SDK to the app and keep secret keys only on your server.
4. Test 3D Secure, saved cards, and refunds one by one in the sandbox.
5. Add Apple Pay and Google Pay as a second step.
6. Submit the app for review with notes that explain the payment flow.

Why can't you use in-app purchase for physical goods and services?

Apple and Google do not want their billing systems used for products that people consume outside the app. On Apple's side, this is a rule, not a choice. Guideline 3.1.3(e) of the App Store Review Guidelines says apps that sell physical goods or services consumed outside the app must use purchase methods other than in-app purchase. It names Apple Pay and traditional credit card entry as examples.

Google, meanwhile, takes a similar line. The Google Play Payments policy states that Play's billing system must not be used for physical goods. The same also applies to physical services such as transportation, cleaning, food delivery, and tickets for live events. In other words, a grocery app that charges through Play billing breaks the policy.

This split also works in your favor. Store commissions do not apply to physical goods and services; your own agreement with the payment provider sets the terms. That said, this freedom moves the card security duty to you and your provider. The rest of this guide shows how to handle that duty well.

When is in-app purchase required instead?

The rule comes down to one question: Does the buyer use the purchase inside the app? Premium features, in-game currency, locked content, and an ad-free version all count as digital content. Apple's guideline 3.1.1 requires in-app purchase to unlock that kind of functionality. Google Play also requires its own billing for digital features and content, although some regions offer alternative billing programs that need separate enrollment.

We covered the commission and web checkout side in detail in our in-app purchase vs. web payment guide, so we will not repeat it here. If you plan a digital subscription instead, our guide on how to design an app subscription model is a better place to start.

There is also a gray zone. Apple lets you use other payment methods for real-time, one-to-one services between two people, such as private tutoring or personal training. However, a live class that one instructor gives to many people at once needs in-app purchase. So when you describe your service, answer two questions clearly: Who receives it, and where do they use it?

Which payment method fits which type of sale?

The table below maps the sale types we see most often in the field to the official rules. In practice, treat it as a decision aid. If your model sits on the line, check the current rule in the official guidelines.

One point stands out. Put simply, a single app can carry both models. For example, a coffee shop app can take card payments for coffee orders and use in-app purchase for an ad-free experience. In that hybrid setup, you need to keep the two flows clearly apart in both the code and the interface.

What is the difference between a payment gateway and a merchant account?

A merchant account is the account a bank opens for you so you can accept card payments online. A payment gateway or payment service provider sits on top of one or more banks and gives you a single API, usually with a ready mobile SDK. Both also let you accept card payments; the real difference lies in integration effort and day-to-day operations.

• Direct bank merchant account: You sign with the bank. If the bank has no mobile SDK, you work through a hosted payment page or a web view.
• Payment service provider: It usually offers saved cards, refunds, and marketplace features out of the box. Its mobile SDKs also tend to be more mature.
• What they share: In both cases, card data goes to the provider's secure systems, not to your server.

We compared the selection criteria in our guide on how to choose a payment gateway. For a mobile app, add one more question: Does the provider offer a current, well documented SDK for iOS and Android? Also check whether it maintains an official package for your framework, such as React Native or Flutter.

How does a payment provider SDK work inside the app?

An SDK (software development kit) is a ready code package from the payment provider that you add to your app. It handles the card form, the 3D Secure screen, and the encrypted transfer of card data to the provider. As a result, the card number never passes through your code or your server. A typical flow looks like this:

1. The user confirms the cart, and the app sends the order to your server.
2. Your server recalculates the total from database prices and opens a payment session with the provider.
3. The provider returns a one-time session key for the app.
4. The app opens the SDK card form with that key, and the user enters the card.
5. If needed, 3D Secure runs and the SDK sends the result to the provider.
6. The provider also notifies your server, and you confirm the order only after that notice.

Both sides then talk through an API. If the term is new to you, our article on what an API is explains the basics in plain words. The most critical rule, however, is simple. Specifically, the provider's secret key never goes into the app bundle. The app file lands on the user's phone and anyone can inspect it, so the secret key stays on your server.

Should the card form live inside the app or on a hosted page?

You have three basic ways to collect card details in an app. Your choice shapes both the user experience and your security duty. The comparison below helps you decide.

In most projects, we recommend the first row. If the provider has no SDK, the second path is also a safe option, but you must build the return from the web view to the app with care. Collecting card numbers in your own form and sending them to your own server turns you into an entity that handles card data. That means a much larger PCI compliance load.

How does 3D Secure work in a mobile app?

3D Secure is an extra security step that verifies the cardholder on behalf of the issuing bank. The user usually types a one-time code from the bank or approves the payment in a banking app. In a mobile app, either the SDK's own screen or a web view that opens the bank's page handles this step.

The most common problems on the app side come from the flow, not the code:

• Users switch to the messages app to read the code and returns to a reset checkout screen.
• Someone approves in the banking app, but your app never listens for the result, so the order stays pending.
• On small phones, the verification screen overflows and hides the confirm button.
• After a timeout, the user tries again, and two payment attempts appear.

For this reason, you need a solid return path from the 3D Secure screen. You should also tie the order status to the server notice, not only to what the app sees. If verification never completes for users, our guide on 3D Secure authentication failures covers the causes step by step.

What do saved cards and tokenization mean?

Tokenization means you use a reference value, a token, instead of the card number. The token points to the card but means nothing on its own. When a user taps "save my card," the provider stores the card data and returns only this token to you. On the next order, you send the token instead of the card number.

Above all, the business benefit is large. Even if someone breaches your database, they cannot reach card numbers, because the token only works with your merchant account inside the provider's system. On the other hand, users no longer type their card on every order. This also shortens checkout a lot, especially for frequent buyers.

Keep what you show on screen limited, too. Specifically, the card brand, the last four digits, and a nickname the user chooses are usually enough. You never store the card security code, neither in the app nor on the server. Also plan for the bank asking for 3D Secure or the security code again on a saved card payment.

What should you watch when you build one-tap checkout with saved cards?

One-tap checkout lifts conversion, but a poor setup damages trust fast. These rules work best in our experience:

• Do not pre-check the "save card" option; let the user choose.
• Add a screen that lists saved cards and lets users delete them with one tap.
• When a user deletes the account, also delete the saved card references at the provider.
• Consider an extra approval layer, such as a biometric lock, before payment.
• Show the total, the delivery fee, and the delivery time on one screen before confirmation.

Saving cards also means you process personal data. For notices, consent, and permission screens, see our guide to mobile app privacy compliance. Note that this section is not legal advice; finalize your texts with a lawyer.

How do Apple Pay and Google Pay fit when you accept card payments in a mobile app?

Apple Pay and Google Pay let users pay with a card saved in their wallet, without typing the number. One detail matters a lot here. Put simply, wallets are not payment processors on their own. The payment still runs through your provider; the wallet only carries the card data in encrypted, tokenized form.

On its Apple Pay developer page, Apple states that you do not receive your customer's actual card number with this method. On the Google Pay side, you pick an integration type. According to the Google Pay API reference, the gateway type sends the token straight to your payment provider. The direct type, where you decrypt the payload on your own servers, requires PCI DSS compliance validated by a Qualified Security Assessor.

In practice, the first task is to confirm that your provider supports both wallets. Next, you complete the merchant ID and certificate steps in your Apple developer account, then the setup your provider describes for Google Pay. For users, the result is clear: fewer fields, fewer typos, and usually a faster checkout.

What do the store rules require when you use Apple Pay?

Apple's guideline 4.9 sets clear expectations for apps that use Apple Pay. First, you must show all material purchase information before the sale. You also have to use Apple Pay branding and interface elements as Apple's marketing and design guidelines describe. For that reason, a button painted in your own brand color or an altered logo can lead to rejection.

If you charge on a recurring basis, for example a weekly cleaning service or a monthly coffee bean delivery, the rules get more specific. In that case, Apple asks you to disclose at least the following:

• The length of the renewal term and the fact that it continues until canceled.
• What the user gets during each period.
• The actual charges the user will pay.
• How to cancel.

This information is also part of good user experience. So even if you skip Apple Pay, we recommend the same transparency in your card form for any recurring charge.

What does PCI compliance mean for your business?

PCI DSS is the standard that defines technical and operational security requirements for entities that store, process, or transmit cardholder data. The PCI Security Standards Council, founded by the card brands, publishes it. Its scope also covers systems that could affect the security of the cardholder data environment.

For a business that wants to accept card payments in a mobile app, the good news is this: the right architecture shrinks your scope a lot. If card numbers only pass through the provider's SDK or hosted page, your systems never touch card data. Still, your duty does not drop to zero. App and server security, secret key protection, and the compliance forms your provider asks for remain yours.

So during the contract stage, ask your provider three questions. Which compliance document do we need to complete for our integration type? Do you require a yearly validation? In which cases does our scope grow? Because compliance requirements can change, always confirm your current obligations with your provider and the official standard.

What server checks do you need to accept card payments in a mobile app?

In practice, the weakest point of a payment flow is often the server behind the app, not the app itself. The phone sits in the user's hand, and anyone can tamper with any value the app sends. That is why we recommend these checks on your server:

1. The server calculates the total: Never trust a price from the app; add up product and delivery costs from your database again.
2. One order, one payment: Give every payment attempt a unique order ID, so a double tap never turns into a double charge.
3. Confirm on the server notice: Mark an order as paid only after you verify the notice the provider sends to your server.
4. Logs: Without card data, record the amount, time, order ID, and provider response code.
5. Key management: Keep test and live keys apart and also rotate them on a regular schedule.

For example, a user may lose the connection during payment, so the app never sees the result. Your server, however, has the notice, and the app shows the correct order status when the user reopens it. This way, you prevent most "I was charged but see no order" complaints before they reach support.

How should you handle refunds, cancellations, and partial amounts?

Refunds come with physical goods and services. An order arrives incomplete, a courier runs late, or a customer cancels an appointment. So plan refunds when you design the payment flow. Otherwise, every refund turns into a manual task in a dashboard, with room for error.

Most providers support full and partial refunds through their API. Some also offer authorization and capture: you hold the amount first and charge the final total later. Example scenario: A grocery app authorizes the cart total, removes items that turn out to be out of stock during picking, and captures only the real amount. Check your provider's documentation for this feature and its conditions.

On the user side, the big question is when the refund will show up. That timing depends on the bank. Instead of promising an exact day, we suggest an honest line such as "this may take a few business days depending on your bank." Showing refund status on the order screen also cuts support load in a visible way.

What hurts conversion the most on a mobile checkout screen?

Even with flawless technology, the checkout screen can lose users. On mobile, the screen is small, attention is short, and every extra field is a chance to quit. These are the mistakes we see most often:

• Forced sign-up: The user has to fill out a long registration form before paying.
• Surprise costs: The delivery fee or service charge appears only at the last step.
• Wrong keyboard: The card number field does not open a numeric keypad.
• Vague error messages: The app says "transaction failed" but gives no next step.
• Missing trust signals: The business name, refund terms, or contact details never appear near the card form.

Most of these mistakes also happen on websites, and our guide on how to reduce cart abandonment shows how to fix them. The mobile app difference is wallet payments. Placing Apple Pay and Google Pay buttons right below the cart removes the card form entirely for many users.

Which accounts and documents do you need before you start?

Sorting out the paperwork before coding starts shortens your timeline a lot. Providers and banks review your business, your product, and your sales terms during merchant onboarding. The document list differs by provider, so get the current list from your provider directly. In our experience, these preparations help:

• Official documents that show your company details and line of business.
• Sales terms, a refund policy, and contact details that users can reach in the app and on your website.
• A clear description of the goods or services you sell, with sample screenshots.
• Apple and Google developer accounts opened in the name of the business.

People often skip the last item. A seller name in the store that matches the business name at your provider helps both user trust and the review process. In addition, a statement descriptor that users recognize reduces "I don't know this charge" disputes. In short, if you collect the documents early, you will not wait for approval when development is done.

Which tests should you run before you accept card payments in a mobile app?

Almost every payment provider offers a sandbox and test cards. No real money moves there, so you can try every scenario safely. We use this checklist before launch:

1. Try a successful payment, insufficient funds, and a declined card separately.
2. Test the right code, a wrong code, and a timeout on the 3D Secure screen.
3. Send the app to the background during payment, cut the internet, and come back.
4. Try saving a card, paying with a saved card, and deleting a card.
5. Check that full and partial refunds show correctly on the order screen.
6. Test Apple Pay and Google Pay on a real device with a test card.
7. When you go live, have two people confirm that the keys belong to the live environment.

The last item looks trivial. Yet an app that ships with test keys cannot take payments, and teams usually notice only after the first orders fail. Also, placing one small real order at launch and then refunding it is the most practical way to verify the whole chain.

How do you avoid store rejection because of the payment flow?

Store reviewers move through your app like real users. If they cannot reach checkout or cannot tell that you sell physical goods, questions and delays follow. So prepare your review notes with care.

• State clearly in the review notes that you sell physical goods or services consumed outside the app.
• Provide a working demo account if the app requires a login.
• If you sell a digital feature, make sure you offer it through in-app purchase.
• Do not leave links that send users to an outside payment page for digital content.

In hybrid apps, the most common problem is a digital perk sold by card, such as discounts tied to a paid membership. In that setup, you need to define clearly what the membership includes and where people use it. If you are unsure, read the relevant guideline yourself and design the model around it instead of guessing.

Is it worth taking payments in an app if you already run an online store?

If you already have an online store, the first question is whether you need an app at all. We covered that decision, with criteria such as order frequency, loyalty programs, and push notifications, in does an online store need a mobile app.

Once you decide on an app, a shared payment setup across both channels works best. You use the same provider, the same order system, and the same refund rules. As a result, a card the user saved on the website can also work in the app, if your provider supports it. Reporting stays in one place too, which makes reconciliation easier for accounting.

Example scenario: A clothing brand uses the same provider on its website and in its app. A user saves a card once on the website, then logs into the app and pays with one tap. This scenario requires both channels to share the same customer account.

Who should build card payments into your app?

Card payments are the most sensitive part of an app, and every mistake costs money and trust. That is why we suggest building the payment flow with a team that knows the store rules and also builds the server side. At Talha Aslan and team, our mobile app development projects set up the provider SDK, 3D Secure, saved cards, and wallets as one flow.

We build your app, prepare it for store review, and publish it to the stores. You only sign the merchant agreement with your payment provider, and our team handles the technical side. If you want to work out which payment method fits your business, tell us about your project through our mobile app development service page and request a quote.