j3k0/cordova-plugin-purchase for Cordova In-App Purchases

What cordova-plugin-purchase solves

cordova-plugin-purchase addresses the problem of implementing in-app commerce from one JavaScript or TypeScript codebase while the application runs on Apple App Store, Google Play, and Braintree environments. It is aimed at Cordova, Capacitor, and Ionic developers who need to sell digital subscriptions, consumable items, or non-consumable content. The repository description also names Windows support through the AppStore, Play, and UWP targets, although the package metadata lists Android, iOS, and wp8 as Cordova platforms.

The plugin is an interface to native purchase systems, not a replacement for those systems. Products must first be configured through the relevant store or provider web interface. The README identifies subscriptions, consumables, multi-quantity consumables, non-consumables, restored purchases, receipt validation, and Braintree payment requests as supported areas. Availability differs by platform. For example, the feature table marks multi-quantity consumables for Google Play but not for App Store or Braintree, and it marks payment requests only for Braintree.

This distinction matters for project selection. If an application needs a single transaction flow for digital goods, the plugin can reduce the amount of platform-specific application code. If it needs uniform feature coverage across every target, the feature table does not support that assumption. The repository also describes direct support for popular payment providers through Braintree, but that is a separate provider path rather than a universal checkout abstraction.

The native purchase and validation flow

The README describes a consistent API across supported platforms, with native implementations for Cordova and Capacitor rather than a JavaScript compatibility layer. The package exposes store objects, product types, platforms, log levels, error codes, and an Iaptic reference. The documented import for Capacitor is `capacitor-plugin-cdv-purchase`, while Cordova exposes `CdvPurchase` globally after installation.

Purchase ownership can operate in two documented modes. With receipt validation, ownership is determined by validating receipts with a server, and `product.owned` reflects the validated status. The README recommends this mode and says it works reliably across TestFlight and the App Store. Without receipt validation, the plugin relies on local device data. In that mode, `product.owned` initially remains false, and `store.owned(productId)` is used to check ownership. The documentation says functionality is limited in test environments without validation.

Receipt validation itself is a server-side step. The repository links Iaptic as a validation service, but it does not claim that Iaptic is the only possible server. The distinction affects failure handling. A local ownership result can be incomplete when the device has not received or retained the expected state, whereas a server-validated result depends on successful receipt submission and the validation service's response. The README does not document offline purchase completion, retry semantics, or a rollback procedure, so those behaviors should not be inferred.

Cordova connectivity also affects retries. The plugin can retry periodically or when the device emits an `online` event. The `cordova-plugin-network-information` plugin is required for that event to be received correctly in a Cordova application. Without it, only the periodic check is available.

Installing the Cordova package and importing its API

For a Cordova application, the README gives the following installation command. It installs the plugin under its published Cordova package name, `cordova-plugin-purchase`.

cordova plugin add "cordova-plugin-purchase"

After installation, the README states that the `CdvPurchase` namespace is available globally. A first application-side step can therefore use the exported `store` object:

const store = CdvPurchase.store;

This is an import and access example, not a complete purchase transaction. The README does not provide the exact initialization, product-loading, purchase-trigger, or event-handling calls needed for a full first sale. It directs developers to the v13.0 guide, the API documentation, and the iOS and Android setup wiki. That omission is a practical limitation of the README as an adoption document: the package can be installed immediately, but real store behavior still depends on following the linked setup documentation.

The same project offers a separate Capacitor package. Its documented installation and synchronization commands are:

npm install capacitor-plugin-cdv-purchase
npx cap sync

The corresponding documented import is:

import { store, ProductType, Platform } from 'capacitor-plugin-cdv-purchase';

The package is primarily written in TypeScript, but Ionic 3 projects may need a compatibility declaration because that environment does not support recent TypeScript notation. The README gives this fallback:

declare var CdvPurchase: any

Cordova HTTP requirements for receipt validation

Receipt validation adds a network dependency that is separate from the native store call. By default, the plugin uses the browser's Ajax capabilities for validation requests. The README warns that this can encounter CORS restrictions and adds an extra request round trip for a CORS preflight.

For Cordova applications that need receipt validation through a server or Iaptic-compatible service, the README recommends `cordova-plugin-advanced-http`. The plugin documentation claims that installing it removes those CORS issues and provides additional HTTP features, including advanced authentication options. The README does not include the installation command for this recommended plugin, so this article does not invent one.

This design creates a specific deployment decision. A Cordova application can use native store APIs through the purchase plugin, while receipt validation may still depend on JavaScript networking and a reachable validation endpoint. `cordova-plugin-network-information` addresses reconnect detection. `cordova-plugin-advanced-http` addresses the HTTP transport and CORS behavior described in the README. They solve different parts of connectivity, so adding one does not remove the need to reason about the other.

Platform coverage, licensing, and upgrade boundaries

The repository contains separate areas for `api/`, `capacitor/`, `src/`, `www/`, platform-related build files, tests, and documentation. The `package.json` identifies `cordova-plugin-purchase` version 13.19.1 and declares MIT licensing. The README states that version 13 includes API changes and links to a migration page. It also says that Ionic 3 should use the plugin without `@ionic-native/in-app-purchase-2`.

The package metadata is not identical to the README's platform description. `package.json` describes Cordova purchase support for iOS, Android, and Windows through AppStore, Play, and UWP. Its Cordova `platforms` list contains `android`, `ios`, and `wp8`. The feature table separately distinguishes App Store on iOS and macOS, Google Play, and Braintree on iOS and Android. An adopter should therefore verify the exact native target and provider path rather than treating the repository description as a guarantee that every feature exists on every platform.

The recent release entries show versioned changes, including v13.17.2, v13.18.0, and v13.19.1. The repository's last push was on 2026-10-14. That is current activity within the stated project history, but the repository does not describe the release cadence, support policy, compatibility matrix, or long-term maintenance guarantees. The README also does not document a general rollback process. Upgrades should be evaluated against the version 13 migration guide and the platform setup documentation rather than treated as package-manager-only changes.

Choosing between the plugin and a provider-specific integration

A real alternative is to implement each store's native purchase API directly in application-specific Cordova or Capacitor code. That approach avoids depending on `cordova-plugin-purchase` as the shared interface, but it also means handling platform-specific product types, transaction events, restoration, errors, and receipt validation separately. The plugin's approach is to place those differences behind `store`, `ProductType`, `Platform`, and related exports, with native implementations for its supported environments.

Another alternative is a provider-centered integration when the application only accepts Braintree payments. Braintree is the documented path for payment requests, and the feature table does not mark payment requests for App Store or Google Play. Such an application may not need a multi-store abstraction, but it would still need Braintree's own setup and request flow.

The choice should follow transaction scope. A multi-platform subscription or digital-content application can benefit from the shared store API. A one-provider application may prefer a direct provider integration because it reduces abstraction around features the plugin does not unify. Neither choice removes the need to configure products, validate ownership correctly, and account for platform-specific restrictions documented by Apple, Google, and Braintree.

Editorial conclusion

Adopt cordova-plugin-purchase when your Cordova application already depends on Apple, Google, or Braintree commerce and can complete each platform's native product setup. Do not choose it as a payment service by itself or assume that the JavaScript package removes platform configuration. Verify App Store, Google Play, Braintree, receipt-validation, and Windows requirements before migration. The MIT license covers the package metadata, but store and payment-provider rules still govern actual transactions. The project was last pushed on 2026-10-14.

Frequently asked questions

Official sources

1. Issues
2. j3k0/cordova-plugin-purchase on GitHub
3. Project website
4. README
5. Releases