React Native Push Notifications, Deep Links and Payments: Key Concepts

How push notifications work

Push notifications pass through platform services: Apple Push Notification service for iOS and Firebase Cloud Messaging for Android. Your app asks the user for permission, receives a device token from the platform and sends that token to your backend. When something happens, such as an order shipping, your backend sends a message to the platform service addressed to that token, and the platform delivers it to the device. Services such as Expo's push service wrap these steps behind one API.

Design the backend side carefully. Store tokens per user and per device, because one person may have a phone and a tablet. Remove tokens the platform reports as invalid. Ask for permission at a moment that makes sense, such as after a user places their first order, rather than on first launch with no context. Use notification channels or categories so users can turn off promotions without losing order updates.

Deep links and universal links

Deep links open a specific screen in your app from a URL. A custom scheme such as fieldorders://orders/42 is simple but only works when the app is installed. Universal links on iOS and App Links on Android use normal https URLs that open the app if installed and fall back to your website otherwise. They require hosting verification files on your domain, as described in the Apple and Android documentation.

Map URLs to screens in one configuration, as shown below, and test every route. Treat incoming link parameters as untrusted input, because anyone can craft a link. Validate IDs, check that the signed-in user may see the requested record and handle links that arrive before sign-in by sending the user through login and then on to the target screen. Push notifications often carry a deep link, so the same routing serves both features.

// Illustrative TypeScript. Check React Navigation's deep linking
// guide and your push and payment providers' docs for current APIs.
export const linking = {
  prefixes: ['fieldorders://', 'https://app.example.com'],
  config: {
    screens: {
      OrderList: 'orders',
      OrderDetail: 'orders/:orderId',
    },
  },
};

// Push: send the device token to your backend after sign-in
export async function registerPushToken(
  deviceToken: string,
  authToken: string,
): Promise<void> {
  await fetch('https://api.example.com/devices', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${authToken}`,
    },
    body: JSON.stringify({ token: deviceToken }),
  });
}

Payments: physical goods versus digital content

Payments in mobile apps split into two worlds, and choosing the wrong one can get an app rejected. Physical goods and real-world services, such as groceries, taxi rides or clinic appointments, are usually paid through a payment gateway like Stripe or Razorpay. Digital goods and subscriptions used inside the app are generally subject to Apple and Google in-app purchase rules. These rules differ by country and change over time, so read the current App Store Review Guidelines and Google Play payments policy for each market.

Whatever the provider, follow one core pattern: the server is the source of truth. The app collects payment details through the provider's own SDK, so card data never touches your servers. Your backend creates the payment or order, and confirms success through a verified server-side callback such as a webhook or receipt validation. Never mark an order as paid because the app said so, because a modified client can claim anything.

• Create payment intents or orders on the server
• Collect card or wallet details only through the provider SDK
• Confirm payment through webhooks or receipt validation
• Grant access or ship goods only after server confirmation

Testing these features

Push, deep links and payments are hard to test in a simulator alone, so plan device testing early. Test notifications when the app is in the foreground, in the background and fully closed, because each case follows a different code path. Test deep links from email, messaging apps and the browser. Use the sandbox or test modes of every payment provider, and include failure cases such as declined cards, cancelled flows and slow webhooks.

Write a short test matrix for these features and run it before every release. For an Indian app, include UPI flows if your gateway supports them; for a Gulf app, include the local cards and wallets your users prefer. At XDQ Labs this matrix lives next to the release checklist so it never gets skipped. Bugs in these three areas are the ones users remember, because they touch money and time-sensitive information.

Check your understanding