Why Payrails agnostic in-app payments
- No platform lock-in – The April 30 U.S. court ruling lets you link to external payment methods, keeping revenue you once lost to up-to-30 % app-store fees.
- Any PSP, any market – Connect to any global or local processor (or Merchant-of-Record) and switch at will, without code rewrites.
- Optimise cost and conversion – Dynamically route transactions for lower fees, higher authorisation rates, or reduced risk, and A/B test strategies in real time.
- Unified data and control – Consolidate web and app payments in one dashboard and experiment from a single rule engine.
- Security built-in – Payrails tokenises data and keeps you in PCI SAQ-A scope.
Intro: your implementation options
Payrails offers two ways to bring checkout into a mobile experience.
Either option lets you decide where the final checkout UI lives:
- Use the Payrails Hosted Payment Page - quickest path, fully branded to your colours and logo.
- Render your own page - host the redirect yourself and retain total design control while relying on Payrails for compliance and payment logic.
Client-side integration options
Option 1 — iOS/RN SDK with Generic Redirect Element (recommended for native apps)
Why pick this? Fastest time-to-market and best user experience—no context switch to the browser, and Payrails maintains the redirect handler for new payment methods.
For complete element documentation, read here - iOS SDK
Option 2 — Server-to-Server Redirect Flow (works for any platform)
- Configure Payrails acceptance workflow to include Payrails HPP option
- Create a Workflow execution with lookup as initial action.
- Take the redirection url from lookup result
- Redirect the user to Payrails Hosted Payment Page
- Handle the return on
return_url, then verify status via API or webhook.
Option 3 - Payrails payment inside the iframe
- Implement your custom payment/checkout page by using Payrails SDKs
- Open it in webview, handle the payment flow inside the checkout page
- Update the status of the app