Mobile Payments in React Native

Kuba distinguishes paid apps and digital in-app purchases from payments for physical goods or services. Paid apps and digital items go through Apple or Google, which may take a 30% cut; physical purchases, such as food delivery, can use a developer-chosen processor. The boundary between digital and physical services can be unclear, and app review outcomes may vary.

Charlie says payment methods depend on where customers are: cards are common in the U.S., while bank debits account for over half of online transactions in some European countries. He also mentions Poland's BLIK, Apple Pay, Google Pay, buy now, pay later options such as Klarna and Afterpay, and Mexico's OXXO vouchers. Apple Pay and Google Pay are separate from app store in-app purchases.

Charlie warns that a breach involving payment data can expose bank details and seriously harm customers. Developers need safeguards in their own apps and should check their processor's security practices. He cites Stripe's HTTPS connections and HSTS as examples.

Kuba advises against building payment processing from scratch because compliance and security are complex, and failures could cost customers money. Charlie explains that Stripe handles connections with financial institutions so businesses can accept different payment methods through its services. The React Native SDK wraps native iOS and Android libraries and offers card input, hooks, functions, and PaymentSheet; a backend integration is also required.

Charlie says Stripe test mode is free, while live transaction fees depend on the payment method; he gives about 2.9% per credit card transaction as an example and points listeners to current pricing. At the episode's close, he asks developers to report bugs and share feedback through GitHub, Twitter, or Discord.