Official plugin to handle with purchases
Guilherme Carpi
I'd like to suggest an official Capacitor library for In-App Purchases (IAP), maintained by the Ionic team.
Currently, many Capacitor projects still depend on the Cordova plugin
cordova-plugin-purchase
(https://github.com/j3k0/cordova-plugin-purchase), which has several limitations:* It was originally designed for Cordova, not Capacitor.
* Maintenance is inconsistent and community support is limited.
* Documentation is often outdated or incomplete.
In-App Purchases are a critical feature for many mobile apps, especially subscription-based products, and having an official Capacitor solution would greatly improve reliability and developer experience.
A first-party Capacitor IAP library could provide:
* Native support for Apple App Store and Google Play Billing
* Subscription lifecycle handling
* Receipt validation helpers
* Modern TypeScript API
* Official documentation and examples
Today, IAP is one of the few major mobile features where Capacitor still relies heavily on legacy Cordova solutions. An official plugin would fill an important gap in the ecosystem.
Martin Donadieu (Capgo)
There is https://github.com/Cap-go/capacitor-native-purchases who is made for Capacitor.
But i agree there many missing officials one.
That why we made so many plugins ^^
Kunal
I completely agree with the need for a better purchasing solution in the Capacitor ecosystem — but I’d like to broaden the scope a bit beyond just traditional IAP.
In today’s apps, purchases are no longer limited to Apple App Store and Google Play Billing. Many real-world applications (especially hybrid apps) rely on global payment providers like Stripe, Adyen, PayPal, Razorpay, etc., depending on region, business model, and compliance requirements.
The real gap:->
Right now, developers are forced to:
- Integrate multiple SDKs (WebView + native + backend glue)
- Handle inconsistent APIs across platforms
- Manage session, redirects, and security edge cases manually (especially in WebView flows)
- Rebuild the same abstraction layer in every project
This becomes even more painful in Capacitor apps where:
- Some flows must use native SDKs (e.g., Apple/Google IAP)
- Others must use web-based or hybrid payment flows (e.g., Adyen Drop-in, Stripe Checkout)
Instead of only an IAP plugin, Capacitor could introduce a unified “Purchase / Payments” layer that:
- Supports App Store & Play Billing (IAP) natively
- Provides a clean abstraction for external payment gateways (Stripe, Adyen, etc.)
- Handles WebView ↔ native bridging reliably (session, cookies, redirects, cleanup)
- Offers a consistent TypeScript API across all payment methods
Bottom line->
An official IAP library would be great — but a broader, first-party payment abstraction that supports both:
- Platform billing (Apple/Google)
- Global payment gateways (Stripe, Adyen, razorpay etc.)
…would be a game-changer for the entire ecosystem.
Martin Donadieu (Capgo)
Kunal for the unified i think it's a bit too complex to put it in one.
There is already a stripe plugin: https://github.com/capacitor-community/stripe
for native payment IAP there is https://github.com/Cap-go/capacitor-native-purchases
and for Payment there is https://github.com/Cap-go/capacitor-pay
maybe with the new SPM feature we could make it one but it migh make the API too complex
Kunal
Martin Donadieu (Capgo),
I get your point about keeping things modular—and I agree a single unified plugin can easily become too complex.
However, from a real-world implementation perspective (especially with Adyen), relying on Web Drop-in inside a Capacitor WebView is not a reliable solution—particularly for Google Pay and Apple Pay.
Key issue:
Adyen and other payment Web Drop-in with GPay/Apple Pay depends on browser-level capabilities that are either restricted or behave inconsistently inside WebViews (both Android WebView and WKWebView on iOS). Even when it partially works, it's not stable across devices, OS versions, or app configurations.
What we’re seeing in practice:
* Apple Pay requires a proper Safari context → WKWebView doesn’t fully qualify
* Google Pay often fails due to missing or restricted Payment Request API support
* Domain verification / merchant validation flows break in WebView environments
* Redirect-based flows behave inconsistently (especially with
capacitor://localhost
vs https domains)So while Web Drop-in is great for web, it becomes a limitation in hybrid apps.
That’s why a native-backed approach becomes important:
* Native SDKs for Adyen and other payment gateway handle Apple Pay & Google Pay correctly
* No dependency on WebView capabilities
* Better UX and higher payment success rates
* Fewer edge-case bugs (especially around redirects and return URLs)
Most importantly, this enables a single codebase that works reliably across all platforms (web, Android, iOS) while still supporting Google Pay and Apple Pay properly—without platform-specific hacks or fallbacks.
From that perspective, having a dedicated Capacitor plugin (or a thin wrapper around native SDKs) for Adyen payments would actually simplify things for developers instead of complicating the API.
👉 For Adyen and similar gateways, GPay/Apple Pay only work reliably via native SDKs rather than Web Drop-in inside WebView—this breaks the goal of maintaining a single codebase across platforms.
🙂