Quickstart on Mobile

​

Configure Products

A Corrily product represents a sellable item, such as a subscription or a one-time purchase.¹

To create a product go to the Products tab under Product Catalog and hit Create Product where you’ll need to define:

• Base price representing the default price to display for this product in the absence of any other prices.²
• Interval and Interval Count if the product represents a subscription.³ If it’s a one-time purchase, you can set Interval to equal one_time.
• API ID, the unique identifier you will use to call for this product.
• Trial Details - you can also allow products to have free or paid trials with configurable trial lengths. You can add multiple different trials to a product, which allows you to experiment with trials.
• Optionally, you can also associate product IDs from web or mobile payment gateways (e.g. Stripe or Apple App Store) to the Corrily product. This step is not required and can be done later in the Integrations tab under ‘Settings’.

Footnotes:

​

Set Prices

Product prices can be further specified in the dashboard’s Prices section under Product Catalog, which shows a tabular view of all prices across every country and audience. Bulk Actions allow you to quickly generate parity prices in specific countries, convert prices from one currency to another, change prices by a certain percentage, or simply set a specific price and currency. You can also use this tabular view of prices to change prices in a given geographic region or countries with low/medium/high purchasing power.

When setting prices, Corrily follows a hierarchy of precedence, as seen in the image below. Country prices take precedence over product base prices. If a user a product price is being fetched for belongs to an audience that has a price, then that audience’s price will take precedence over a country price tied to where the user is from. Finally, experimental prices take precedence over all other prices apart from direct price overrides.

​

Locking prices to users

When products are requested for users using the prices endpoint the returned prices are locked-in by Corrily and all subsequent calls (unless overriden) will return the same prices.

​

Other actions that impact price

Additionally, other actions might affect the price fetched. These include coupon applications, which take either a fixed amount or a percentage off a price; rounding rules, which shift prices to look nice; or requests for a locked price to be displayed in another currency.

​

Charging Users Corrily Prices

Corrily has the ability to return all sorts of prices. These might be specific to a country, or an audience, or they could be an experimental price. Regardless, the universe of possible Corrily prices is often greater than the base product or plan prices you have set in your payment gateway. Below are the ways we suggest you accommodate this in both web and mobile.

​

Web

When integrating with web payment gateways or subscription management services the Corrily proposed price can be passed as a price override. Users are still subscribed to the same plan or purchase the same product, but with a custom price different to the gateway-defined base price.

Corrily provides the exact amounts and currencies you should charge in the product.integrations field of its response.

You can read more about how price overrides work in different services:

• Stripe (via payment intents, subscription creation, or checkout sessions
• Recurly (see unit_amount)
• Chargebee
• Braintree
• Adyen

​

Mobile

Charging prices on mobile is different from the web in that mobile prices (in-app products in both Google and Apple) cannot be overriden. A mobile in-app purchase product has a fixed price (or fixed set of prices across countries) that cannot be easily changed. As a result, to be able to charge audience or experimental prices on mobile, new products at different price points need to be introduced.

As an example, say you had a monthly product monthly, and wanted to charge students at half the price you charge normal users as well as run an experiment to see whether your baseline monthly product works best at the current price, half the price, or 1.5x the price. In that case you would need to create two additional products monthly_0.5 and monthly_1.5. You could then rely on Corrily’s segmentation logic to show select groups, such as the students, the monthly_0.5 price and on Corrily’s experimentation logic to study whether monthly_0.5, monthly, or monthly_1.5 price points work best.

​

Receiving Revenue Events

Integrating payment gateways and subscription management services to receive revenue events.

For Corrily to run experiments and serve analytics it needs to receive information about revenue events these include: charge events and, in the case of subscription products, subscription events too.

There are two ways to go about this:

• Via webhook: where your payment gateway or subscription management service sends event data directly to Corrily’s servers that parse it and join in to the user-level features, prices, and other metadata collected through Corrily’s APIs. Supported services include:
  • Stripe
  • Recurly
  • Chargebee
  • Braintree
  • Adyen
• Through the custom integration API: where you send key revenue events to our custom integration endpoints.