Skip to main content

· 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!

· 2 min read


react-native-iap is a great module to implement In-App purchases in your React Native App.

But react-native-iap will only provide you the client side code to implement IAP, you'll still have to develop a backend in order to validate the IOS/Android receipts and extract the purchases of the user.

AFTER
... 50 hours trying to understand how to parse an Apple receipt
... 20 hours trying to understand how to parse an Android receipt
... 200 hours of DEV
... 5 hours explaining to your GF why you can't go out anymore
... and 42 coffees

You might have a backend validating your IAP. 😅

But you're still subject to potential errors without an extensive testing and you probably won't have other much needed features such as a dashboard to report real time analytics, a system to remotely update your products, a system to perform A/B testing... and many more tools that will help you increase your revenue.

If you feel like you should spend your precious time developing your app instead and (SPOILER ALERT) you definitely should.

You should definitely give a try at IAPHUB.

Using the React Native module react-native-iaphub you'll be able to process IAP on your app in no time!

And good news! If you're developing a new App and you have a tight budget, the FREE plan (which has all the features) should be enough until your app gains some traction.