How to test Google's In-App Purchase

Danish Shah — Wed, 13 Apr 2022 21:32:05 +0000

Here's the cheatsheet on how to test Google's In-App Purchase.

While I was trying to implement IAP I had to go through a lot of trial and errors.

Here's what you need to know to test Google IAP:

Google Play Store Setup

To be able to test Google IAP you need to have a few things setup prior you begin your testing.

You need to publish an initial version of your app on play store in production

To start testing IAP you need the base version of your app to be published on play store, this allows google to fetch all the details related to your app when IAP is triggered from your app. If this is not done and you try to initiate IAP from the app, it'll throw an error saying The item you are trying to purchase couldn't be found. That being said you need an initial version of your app to be published, note that the initial version of app doesn't necessarily have to have IAP implementation, just a base version of app will work.

Deciding on how to sign your app

When you'll be publishing your initial version of app you'll need to sign your APK before publishing. There are two options for this:

You can create and manage keystore and sign your app on your own
Let google create, manage and sign your app

Note that you can opt for either of the approach and cannot switch between once the app is published.

The difference between the 2 is that in the first one you upload a signed APK on play store and in the other one you upload AAB (Android App Bundle) on play store and google signs it and creates an apk for you.

Both options have pros and cons specifically for testing iap, lets discuss that

Creating, managing and signing your own app

To do this you need to generate a keystore from Android Studio and use that to sign your app's APK before every release.

Now to test IAP you need to have a signed APK, otherwise you will not be able to initiate the purchase flow

The main advantage with this approach is having an initial version of app published on play store you can just create new signed APK's, install them on your device and test it.

There's no disadvantage to this approach per se, but the only reason I'd not recommend you to manage keystore is if you loose the keystore you will not be able to update any app that's was signed by that keystore ever.

This is where google signing keys comes into place

Using Play App Signing

This is a simpler approach where google create, manages and signs your app's IAP and you don't have to worry about loosing your keystore ever. Now to do this instead of uploading an APK you upload an AAB instead. Google will take care of everything from that point.

Note that every-time you create a new release it take a few hours before google publishes to the users

This approach is the best and I'd recommend this, but when it comes to testing IAP this becomes a pain. Since you don't have access to the keystore the app is signed with, every-time you need a signed APK you need to upload a released AAB on play store and test the new app.

Testing Environments

Now that you've uploaded an initial version of your app without IAP, you can start implementing IAP on the next version of your app. Now you need to create In-App products and Subscriptions on Google Play Console. To test the app with actual payment processing you need to release it either in production or one of the testing environments. Ideally you want to release it in a test environment so can test it and handle all the edge cases.

There are multiple options for creating a test env, For the purpose of this post. I'm gonna explain only the Closed Testing environment. For this you need to create a new track and upload you APK or AAB depending on how you decided to sign your app. Once that's done you can roll it out to tested. The list of tester can be managed in the track itself.

With this you'll be able to download the new version of your app and test it in a isolated env.

Publishing the final version

Once you've tested your IAP implementation and handled all the edge cases you can release the app to production. This can be done from the track you used for closed testing. It takes a couple of hours to roll out the final version to your users

Bonus

I wrote a nice hook in react-native you can use

import * as RNIap from 'react-native-iap'
import * as Sentry from '@sentry/react-native'
import { Alert } from 'react-native'
import { useEffect, useLayoutEffect, useRef, useState } from 'react'

import { useIap } from 'components/iap/IAPManager'

const useInAppPurchase = (itemIds, type = 'product', isPurchased = false) => {
  const itemIdsRef = useRef(itemIds)
  const { getProducts, getSubscriptions, setProcessing } = useIap()
  const [products, setProducts] = useState([])
  const [subscriptions, setSubscriptions] = useState([])

  const requestPurchase = async (itemId, onPurchaseStart, onPurchaseEnd) => {
    try {
      setProcessing(true)
      await onPurchaseStart?.()
      await RNIap.requestPurchase(itemId, false)
      await onPurchaseEnd?.()
    } catch (err) {
      setProcessing(false)
      // eslint-disable-next-line no-console
      console.error('IAP Hook', err.code, err.message)
      Sentry.captureException(err)
    }
  }

  const requestSubscription = async (itemId, onSubscriptionStart, onSubscriptionEnd) => {
    try {
      setProcessing(true)
      await onSubscriptionStart?.()
      await RNIap.requestSubscription(itemId, false)
      await onSubscriptionEnd?.()
    } catch (err) {
      setProcessing(false)
      // eslint-disable-next-line no-console
      console.error('IAP Hook', err.code, err.message)
      Sentry.captureException(err)
    }
  }

  useLayoutEffect(() => {
    itemIdsRef.current = itemIds
  })

  useEffect(() => {
    const fetchProductDetails = async (ids) => {
      setProducts(await getProducts(ids))
    }

    const fetchSubscriptionDetails = async (ids) => {
      setSubscriptions(await getSubscriptions(ids))
    }

    if (type === 'product' && !isPurchased && itemIdsRef.current?.some((item) => !!item)) {
      fetchProductDetails(itemIdsRef.current)
    }

    if (type === 'subscription' && !isPurchased && itemIdsRef.current?.some((item) => !!item)) {
      fetchSubscriptionDetails(itemIdsRef.current)
    }
  }, [getProducts, getSubscriptions, isPurchased, type])

  return {
    products,
    subscriptions,
    requestPurchase,
    requestSubscription
  }
}

export default useInAppPurchase

Usage:

const { products, requestPurchase } = useInAppPurchase(productIds, 'product', isPurchased)
const { subscriptions, requestSubscription } = useInAppPurchase(subscriptionIds, 'subscription', isSubscribed)

requestPurchase(purchaseId)
requestSubscription(subscriptionId)

Writing cleaner React code

Danish Shah — Wed, 13 Apr 2022 21:26:18 +0000

This article is not about low-level guidelines on writing clean code. This article focuses on high-level concepts that are not addressed or often talked about.

We often hear about writing clean code, when it comes to React we are told to write smaller components or break large components into smaller ones. While this is true this certainly doesn't clarify how you can write cleaner components.

Here is a small set of slightly opinionated rules you can follow while writing a react component.

Enforce a consistent structure while writing components.

Enforcing a simple structure to your components makes it easier to navigate and read your code. Although this looks simpler, it can be difficult to get used to it at first. To hack this start writing comments for each section, once you are comfortable enough you'll start to see those comments fade away while maintaining the structure.

Here's a simple example of how you can write a component by following a structure.

// Sort imports alphabetically

// Package Imports
import merge from 'lodash/merge'
import React from "react";
// Package Type Imports
import type { Resolvers, TypePolicies } from '@apollo/client'
import type { useState, useEffect } from "react";

// App Imports
import BarChart from 'components/charts/BarChart'
import Block from 'components/blocks/Block'
import Card from 'components/card/Card'
import Loader from 'components/loaders/Loader'
// App Type Imports
import type { BlockProps } from 'components/blocks/Block'

// Component types
type ComponentProps {
 ...
}

// Styled components
const StyledText = styled('p', {
 ...
}

// Constants or variables that's has no effect on rerender
const URL = "https://www.google.com/";

const CleanComponent = (props) => {
  // Store/State/Callbacks/Refs/Context/Memo
  const [open, setOpen] = useState(false);

  // UI State
  const [isLoading, setIsLoading] = useState(props.isLoading);

  // Events
  const handleAction = () => {
    setOpen(true)
  }

  // Networking
  const fetchDataFromAPI = () => {
    fetch(URL).then(() => {
      // do something
    })
  }

  // Effects
  useEffect(() => {
    // do something 
  }, [])

  // JSX
  return (
    <div>
      <p>Writing clean react code</p>
    </div>
  )
}

// Type exports
export type { ComponentProps }

export default CleanComponent

Component Abstraction

While this is the most powerful concept it is highly misunderstood. Deciding when to break a component into smaller ones or not is something that comes with a lot of practice, but there are some rules you can follow when in doubt.

Components that are at same level of abstraction should be together

When writing components you often get a feeling of breaking it into smaller components, but it's not really a sub-component. When components are on the same level of abstraction just keep them in the same file or create a components folder for that component.

const Menu = () => (
  <i className="fa fa-menu" />
)

const Navbar = () => (
  <div>
    <Menu />
    <h1>App</h1>
  </div>
)

Deciding when to break a component into smaller ones

This is non-trivial, especially when you are working on a complex component. To solve this, make a set of rules that you follow when your component becomes too complex.

Follow the Single Responsibility Principle.
Reusability is another important criteria for breaking components. If you see yourself writing the same component, again and again, try abstracting it out
When you see a clear abstraction i.e. when a small part of your complex component can be extracted out and live in its own world (this includes everything like local state, network call, event handling, etc).
When component props goes higher that some number x. This is an indication that your component is becoming complex and needed to be broken into smaller components

DEV Community: Danish Shah