Skip to main content

· 2 min read

We're happy to announce the release the version 8.4 of the React Native plugin.

This new release has quite a few enhancements and a new method getBillingStatus that has been added in order to easily detect an error with the billing system.

When the billing system is unavailable, the products for sale will be filtered and an empty array will be returned.
You can use the getBillingStatus method (after fetching the products) to detect when it is the case in order to display the appropriate error message.

On Android, we also recommend displaying an error message when the billing system is unavailable because the Google Play Store app is outdated (it can happen on old devices with an outdated software). Tell the user to open the Play Store app and go to Settings -> About and click on Update Play Store.

If the getBillingStatus method doesn't return any error but your product is missing, it is most likely a misconfiguration issue.

You should check the filteredProductIds property.
If your product ID is in the array, it is an issue with GooglePlay/iTunes (we are relying on them to fetch the products details). Otherwise it is an issue with IAPHUB. Please follow this guide to walk through the different possibilities that could cause this issue.

var status = await Iaphub.getBillingStatus();

if (status.error && status.error.code == "billing_unavailable") {
  if (status.error.subcode == "play_store_outdated") {
    // Display a message on your paywall saying that the Play Store app on the user's device is out of date, it must be updated
  }
  else {
    // Display a message on your paywall saying that the in-app billing isn't available on the device
  }
}

if (status.filteredProductIds.length) {
  // Some products have been filtered because they were not returned by GooglePlay/iTunes
}

Enjoy!

· 2 min read

We're happy to announce the release the version 8.3 of the React Native plugin.
This new release is shipping some really helpful features!

What's new?​

A new onDeferredPurchase event​

Thanks to this event you'll now be able to easily detect when a new purchase occurs outside of the buy method.
For instance this event can be trigerred:

  • After a purchase is made outside the app (by redeeming a promo code on the store by example)
  • After a deferred payment (when the error code 'deferred_payment' is returned by the buy method)
  • After a payment fails because it couldn't be validated by IAPHUB (and succeeds later)
  var listener = Iaphub.addEventListener('onDeferredPurchase', async (transaction) => {
    
  });

The enhancement of the restore method​

The restore method will now return a RestoreResponse object.
This object will contain two properties:

  • newPurchases: The new purchases processed during the restore
  • transferredActiveProducts: The active products transferred (from another user) during the restore
var response = await Iaphub.restore();
// New purchases
console.log('New purchases: ', response.newPurchases);
// Extisting active products transferred to the user
console.log('Transferred active products: ', response.transferredActiveProducts);

New properties for the ActiveProduct object​

We've also added a few extra properties for the active products.

  • isPromo
  • promoCode
  • originalPurchase

Enjoy!

· One min read

As you know we're on a mission to make in-app purchase as easy as possible.
The react-native-iaphub is already doing that pretty well but we've decided to make things even easier!

Our new React Native component react-native-iaphub-ui will now provide all the UI necessary to sell in-app purchases!
You'll be able to display a beautiful paywall that is highly customizable and includes (so far) the translations in 6 languages (English, Spanish, French, German, Portuguese, Japanese).

Here is a little preview of the component (the image and title isn't part of the component):



The usage of this component is of course totally optional but we're sure it'll help a lot of developers trying to deploy in-app purchases fast. The development of a great paywall takes a lot of time 🙂.

· One min read

IAPHUB will now send the iOS/Android promo code the user used during a purchase!

The new promoCode property will be sent on a purchase webhook or when fetching a purchase from the API.
And the promo code will also be displayed on the IAPHUB dashboard when clicking on a transaction.

Google only returns the promo code for subscriptions vanity codes (not available for one time codes).

Also for iOS the promoCode property will contain the offer reference name you've provided when creating a promo code on iTunes.

· 3 min read

A major update has been pushed! 🥳

The iOS & Android SDKs have been upgraded to v3, and the react-native-iaphub library to v8, we recommend updating the library to the latest version.

The big change is that our Android SDK is now using the Google Play Billing Library version 5!

What's new with the Google Play Billing Library version 5?​

You might have noticed Google released some new features in May 2022 (Google documentation).

Basically everything got a little more complex in order to offer new features (but fortunately you have IAPHUB to make things a little easier for you).

In short:

  • A subscription product has now the possibility to have multiple offers.
  • Each offer has the possibility to offer multiple intro phases (up to 2).

What's the changes in the SDK update?​

Multiple offers​

If you have multiple Android offers, the oldest (first one you've created) will be used by default. We've decided to not support multiple Android offers in order to have a common system with iOS.

To have a different offer simply create a new product, you can do pretty much everything with smart listings.

Multiple intro phases​

Since Android now supports multiple intro phases (you can now for example offer a free trial followed by an introductory price), we had to change our API which is why it is a major update, but updating the library should be pretty easy.

So what's the differences with the new API? The following properties have been removed:

  • subscriptionIntroPrice
  • subscriptionIntroLocalizedPrice
  • subscriptionIntroPayment
  • subscriptionIntroDuration
  • subscriptionIntroCycles
  • subscriptionTrialDuration

Instead you'll have a property subscriptionIntroPhases that is an ordered list containing the intro phases the user is eligible to.

So for instance, if you create 2 intro phases: a free trial of 1 month followed by an introductory price of $4.99 for 3 months, the subscriptionIntroPhases property will contain the following:

[
  {
    type: "trial",
    price: 0,
    currency: "USD",
    localizedPrice: "FREE",
    cycleDuration: "P1M",
    cycleCount: 1,
    payment: "upfront"
  },
  {
    type: "intro",
    price: 4.99,
    currency: "USD",
    localizedPrice: "$4.99",
    cycleDuration: "P1M",
    cycleCount: 3,
    payment: "as_you_go"
  }
]

And also if the user isn't eligible to any intro price/trial, the array will be empty (or null if it isn't a subscription). Easy right?

We're here to help​

If you have any questions or issues upgrading the library to the latest version, you can of course contact us at [email protected].

· One min read

Today we're releasing a new feature that was requested by our users! Our webhooks are now sent from static IPs, which is quite useful if you're looking to whitelist our IPs on your firewall.

Our webhooks will be sent from the following IPs: 18.190.151.13 and 18.218.125.16.

Enjoy 🙂

· 3 min read

You might have received an email from Apple about the new european legislation starting on December 31, 2020 (https://developer.apple.com/support/psd2/).

Basically some users in the EU purchasing your in-app products will have to be redirected to a webpage of their bank to complete the payment.

We were thinking StoreKit would work exactly like ApplePay which already meets SCA requirements and doesn't need any redirection to complete the payment but surprisingly it doesn't!

On the other side Google did not communicate at all about how SCA will affect the in-app purchases on Android.

We contacted Apple and Google to get more information and we'll share with you anything interesting we learn 🙂.

In the meantime here is what we know.

How does it work exactly on iOS?​

Apple said it's gonna be the same as:

  • When a kid use the Ask to buy feature to ask the permission of the parents to buy an in-app product.
  • When a user need to agree to updated App Store terms and conditions before completing a purchase.

We are still waiting to get more information from Apple about that subject because these two features work a little bit differently:

You can test your implementation pretty easily by emulating an interrupted purchase (Agreement requirement) on the App Store Connect:

  • Go to Users and Access
  • Click on Sandbox -> Testers in the left menu
  • Click on your sandbox user
  • Enable the checkbox Interrupt Purchases for This Tester

How does it work exactly on Android?​

We are still waiting to get more information from Google (surprising they did not communicate about it) but we assume it'll work just like a Pending transaction.
It may also just work like a regular transaction which would be very smart from Google to avoid any potential issue on existing apps.

A pending transaction will trigger a purchase with the state PENDING followed by the state PURCHASED if the transaction is a success.

You can test your implementation by using the 'Slow test card' option when purchasing a product in sandbox.
For some reason the option is only available for products, not subscriptions.

I'm using IAPHUB, what should I do?​

  • You should update react-native-iaphub to the latest version (v6.0.3), otherwise the purchase will still be processed but the buy method might throw an unexpected error.

  • You should double check you're handling the case the buy method throw a deferred_payment error, example here.

  • If you're migrating from v4 or v5, the only breaking change you should check is the getActiveProducts() method that introduce the new subscriptionState property and doesn't return subscriptions on a paused or retry period by default, more informations here.

· One min read

If you're a member of IAPHUB you should have already received an email from us a month ago about the upcoming release of IOS 14.

We would like to remind everyone that your react-native-iaphub library must be up to date in order to support IOS 14!

A bug has been found in react-native-iap on IOS 14 (which is a dependency of react-native-iaphub) causing the promise of the buy method to not resolve!

The fix has been deployed in the version 4.5.2 of react-native-iap (PR here) and the react-native-iap dependency version has been updated in the version 4.1.0 of react-native-iaphub.

Even if you've updated the react-native-iaphub library we recommend double checking that you've the latest version of react-native-iap.

Do not forget that after updating the library using npm you must call pod install as well to update the Objective-C files of the react-native-iap library.

· One min read

We just released a new feature you should definitely like if you end up with a bunch of failed webhooks!

An awesome member of the IAPHUB community (Thanks David!) had the issue and suggested that we implement a 'bulk retry' feature to retry multiple webhook requests in a few clicks (instead of going on each webhook page to retry the request).

We thought it was a great idea and we're happy to announce the feature is now live 🥳!

To enable the feature, just click on the "three dots" icon of the webhooks page, a menu will appear to enable it.



When enabled you will have the ability to select the webhooks you want to retry.



After selecting the webhooks, click on the RETRY button to start the retry process.



Enjoy!