Loading...
Home
All Projects
Connect

Multi Currency

At Mighty Networks, I ran the Money & Members squad, handling all projects related to payments and how members join online communities. I developed a 3 year plan on how to overhaul our payment collection system, and give hosts the freedom and flexibility they wanted when it comes to charging members. The first major milestone and largest return on investment came from building out multi currency to open us up to an international market.

Product Manager & UX Designer

Managed and led design on a team of 12 software engineers, 2 designers, and 4 QA engineers (Nov 2020 - May 2021)

25% Of All One Time Purchases Were Not In USD Three Months After Release

Product Management
Experience Design
Figma
Vision Definition
Competitive Analysis
Iterative Development
Interface Design
About the ProductStage 1: Redesigning Pricing DisplaysStage 2: Charge Over $1,000 USDStage 3: Handling AndroidStage 4: Multi CurrencyResultsThe Future

About the Product

Mighty Networks allows Hosts to create communities they can call home. However, we currently restrict how they accept members by forcing them to choose one of four privacy settings. Each of the four have their own features which are exclusive to it, which causes a lot of confusion for Hosts.

Public

Public communities allow anyone to see what's going on inside, and everyone is able to create an account.

Private

People can find the community but can't see any of the content within. They have to get approval from the Host to join the community, and answer any screening questions the Host sets.

Secret

Without an invite link, people won't know the community exists and cannot find it on Google or Mighty Network searches. Anyone with an invite link can join only by clicking the invite link.

Paid

No one can see any posts in the community, but anyone can purchase access to it. Hosts can set up multiple plans people can purchase that provide access to the community.
Each of these privacy settings can be used for the larger community (Network), or any of the spaces within the community (Groups or Courses). As an example, if you have a public network with a paid course and a secret group, a visitor could see inside the network, but would be prompted to create an account and buy access to a course before being able to see its content. Once inside the network, the member still would not be able to see the secret group unless someone shared an invite with them.

Duncan E.

"Why do I have to have .99 on all my prices? It feels like I'm trying to swindle people. If I'm charging $500 I want people to know what I'm charging. Also needing that decimal makes the price look even longer ($499.99 looks outrageous)."
Intercom Help Request

Beth F.

"Can someone please help! My plans have been in review for weeks and my launch is TODAY!!!! All of my marketing work will be wasted if nobody can get into my network!"
Intercom Help Request

Tessa R.

She runs her community in England and all of her members are European. She is worried that her courses aren't getting purchased because they are being offered in USD instead of Euros like everything else in Europe. It makes her look unprofessional.
Host in a weekly workshop
There were a lot of requests by customers to mix and match elements of the settings, and confusion around how to make their onboarding work for them. The most confusion centered around paid spaces, so we focused our efforts there to start.

Constrained By Apple

When originally designing our payment system, Mighty Networks set up Stripe for Web and Android purchases and worked with Apple to integrate their in-app purchase software into the platform. Apple requires all purchases on their platform to be in-app purchases unless they are donations, physical goods, or event tickets. Apple lets many large companies avoid these restrictions in favor of having higher device usage, but is stricter with smaller companies who don't bring enough users to push back. For example, Mighty Networks has the exact same payment structure as Patreon, but Patreon is not required to use in-app purchases while Mighty Networks is.

Mighty Networks wanted to make the payment plan creation form simple and keep the rules the same on all platforms. However, this meant taking on the most restrictive rules and forcing them onto platforms that didn't require it.

At the time, Apple was the most restrictive with their rules which caused several problems.

1

Pricing Intervals

In-app purchases have set pricing that developers have to use. At low values it jumps by one dollar at a time from $0.99 to $124.99, then jumping by five dollar intervals to $299.99, jumping again by fifty dollar intervals after that, maxing out at $999.99. While apps like mobile games rarely have reason for any purchase more than $99.99, an online course can cost thousands.

Users also disliked being forced into using charm pricing because they wanted control over what they charge.

2

10,000 Payment Plans

Apple limits any app to have at most 10,000 plans. For an app where an important piece is allowing users to create payment plans, we quickly hit 10,000 and would regularly have to purge un-purchased plans, as well as begin rationing plans to only networks that would use them heavily.

3

Review Process

Apple has a required review process for every plan in an app on their platform to make sure it meets their guidelines. This process can takes weeks depending on the backlog, which caused customers to miss their community launch dates.

There isn't visibility into how long Apple's process will take, which causes hundreds of customer complaints to be sent to us every month asking why their plans aren't approved yet. The review process varies wildly by which reviewer is assigned to the plan, and while with one reviewer, a certain plan will pass without qualms, another reviewer will reject a similar plan without explanation as to why. Because of this lack of clarity we regularly had to work with clients to re-setup their payment and resubmit, delaying them weeks of income.

4

Currency Conversions

Apple is super helpful and will convert prices into a users currency when they are viewing an app. However many hosts would complain that the converted price doesn't look right to their audiences. For example, a $24.99 USD plan would be £18.44 GBP. The apple developer account needs to have a single set currency for all payments, and so plans needed to be set in USD because that's where the majority of our business takes place within the Mighty Networks app. Stripe does not do auto conversions and at the time restricted a user to only be allowed to use one currency per credit card in the system. This meant we could only support USD payments on Web and Android. This caused a lot of friction for international hosts because users thought they were untrustworthy when not offering payment options in the country the community was being run in.

5

Management Prevention

Apple does not allow hosts to move a member between plans, even if the new plan offers more and costs less. Many hosts offer bundles in Mighty Networks where if you purchase several courses together you can get a discount. A user can't purchase the same content twice in Apple. If they had purchased one of the courses in a bundle, they could not upgrade on iOS without canceling their plan.

6

30% Fee

Apple collected a 30% fee on all transactions made in their app, which is a large income loss to a small business trying to stay afloat with online communities. We had built a special option to increase prices by 30% just on iOS devices to try and alleviate some of that pain, but with the fixed pricing options and limiting price cap, Hosts couldn't always increase the price reasonably.

7

Cannot Mention Other Purchase Options

One of the main reasons plans would get rejected is that a host would mention things like the web address to purchase another bundle or talk about payments outside of iOS. This is strictly prohibited by Apple and caused many hosts to have to resubmit plans.
All of these restrictions caused a lot of pain for users and caused them to handle payments off of our platform. In order to reach the international community and fix these pain points, we eventually arrived at the decision that we had to split apart Apple In App Purchases and Stripe Payments. If Hosts wanted to charge on Apple, they would have to follow their rules, but those rules should not dictate how someone can purchase on the Web or Android.

Stage 1: Redesign Pricing Displays

We show the price in many places throughout our product, all of which had to change to be significantly more flexible to accommodate all the new forms the price could take.

1

Higher Prices

The first thing the new pricing display needs to be able to do is allow for higher prices. Once we split Stripe plans from Apple's rules, we could charge significantly more. At the time of design the business team hadn't decided how much we were going to allow, and so I prepared to match Stripe's maximum purchase value of $999,999.99 USD.

2

Longer Prices

Not only did we plan on raising our pricing caps for Web and Androids plan, but other currencies can add up to six digits on a price. For example, 10,000.00 United States Dollars (USD) is equivalent to 3,363,818,213,713,137.00 Venezuelan Bolívares (VEF). Whatever the design, it needs to be able to accommodate such large prices.

3

Charmless Pricing

While charm pricing has been shown to make people more likely to purchase, many hosts felt like it came across as squeezing pennies from their members. We needed to provide a way for them to opt out of it.

4

Moving Currency Symbol

The placement of the currency symbol ($, €, ¥, etc.) depends on the language spoken in the location of purchase. And so the price had to reference a location database to determine where the currency symbol should go.

5

Changing Formats

The price also needed to accommodate the correct format, as different countries display prices differently. For example, while USD uses commas to denote the thousands place and decimal points for the cents (##,###,###.##), the Euro uses the opposite (##.###.###,##). Our structure had to be flexible enough to accommodate a range of formats.
Plan
Creation
Checkout
Settings
When viewing landing pages, people see cards displaying different purchase options. These plan cards needed an updated design in order to accommodate the new pricing. (We also created space for adding images to plans in this update)
Once inside the plan page, the header displays every price of a plan along with a description of everything someone gets when they purchase it.
Lower down on the plan page is a list of each space someone is getting access to with the total price listed at the bottom.
When creating a plan, the inputs needed to be updated to allow for custom prices.
At the bottom of the creation form we display a preview of plan card which matches the display in the plan section.
On the left hand side of credit card input form, we display the price of what is being purchased along with the tax. This tax value also had to reference tax laws. for the location of purchase.
After creating a plan, when viewing its settings we display its price so people can easily review it.
All of these areas needed at least minor redesigns to become flexible enough to accommodate the longer prices. After getting through that prep work we could actually dive into splitting apart Apple from out payment plan.

Stage 2: Charge Over $1000 USD

Once we did our prep work of making the platform more accommodating to different prices, we could actually dig into the backend and creation form to untangle Apple Plans and Stripe Plans.

1

Choose This Plan's Platform

The first thing we had to do was allow people to choose what platforms they wanted to sell their plans on. Now, if they want to sell on iOS, the iOS part of their plan will need to follow Apple's rules, but we allow people to not sell on iOS at all.

2

Create Stripe Plan

If they choose to sell on Web and Android, the pricing can be up to $10,000 and is a text input field so they can format it however they want including not showing cents. They can also have a different free trial length on Web and Android than on iOS.

3

Create Apple Plan

On the iOS part of a plan we had to restrict people to only selecting from Apple's preset options, and explain that Payouts and Taxes will work differently for Apple plans.

If someone chose not to sell on iOS, we also had to explain what would happen. Apple does not allow content that is purchasable on Web but not purchasable in the app to be visible in the app (This is also one of those things that only applies to small companies, and not larger ones like Amazon and Netflix). So if a course or group has a plan available on Web but none on iOS that space would not appear in the app.
Once we split apart Apple plans, we were able to let people charge over $1000 dollars. We released this on April 19, 2021, and in the first 24 hours had 15 plans created at over $1000 dollars. Now on average nearly 6% of all payment plans offered are over $1000. Nine months later we have had a) over 416 one time purchases ranging from $1,000 to $10,000 USD, b) 40 monthly subscriptions joined at over $1,000 USD, and c) 154 annual subscriptions sold ranging from $1,000 to $5,000 USD per year.

Stage 3: Handling Android

Almost as soon as we finished splitting apart Apple's in-app purchases from our Stripe plans, we found out that Android was changing their in-app purchase policy so that every app could no longer use external services for payments if they were not for physical goods or in person services.

The one major difference between Android and Apple was that you could mention other methods to purchase in an Android app.

After researching all possibilities and looking at Android usage, only 4% of all traffic in our app was on Android devices and the amount of money we could make off of Android purchases would not come close to the amount of developer work it would take us to integrate Android plans, or the amount of work it would take to manage those plans.

So we had to take a few sprints to fix the language in the creation form and all purchase flows in the android app to stop collecting payments in it.

Stage 4: Multi Currency

Once we had split apart Apple and Stripe Plans, we could fully dive into Stripe's requirements for charging in multiple currencies.

1

One Currency Per Customer

The biggest challenge that came up in how Stripe handles currency is that every customer can only have one currency associated with their credit card. This means after making one purchase with a credit card, all purchases with that saved card need to be in the same currency. Our system is designed to only have one saved credit card per member.

To solve this we had three options, 1) lock people into one currency after their first purchase on Stripe, 2) create a new Stripe customer for each purchase, or 3) allow people to get a refund and repurchase everything in a new currency if they wanted to switch. Options two and three required a significant amount of backend work and would bring confusion to the users. We decided to go with option 1 in the short term and evaluate options 2 and 3 as follow ups if we got complaints about not being able to switch currencies.

A few weeks before we released Multi Currency, Stripe announced they were actively working to change this policy. So, we decided to not take option 2 or 3 and wait for Stripe to complete the ability to have more than 1 currency.

2

Presentment vs Settlement

There are two types of currency in Stripe that are defined by the country you have set up your account in.

Presentment Currency is any currency you are allowed to present a payment in. If you are operating in the US you can display a price in over 150 currencies. Payments from these will be converted to a settlement currency before being transferred to your bank account. If a user can purchase in their own currency they don't incur a conversion fee.

Settlement Currency is a currency that you can receive payouts in. If you are based in the United Kingdom you can attach a bank account that runs in British Pounds or Euros, and have all payments come to one of those bank accounts. If your country allows it, you can also have multiple settlement currencies. If you settle in the same currency as the purchase was made in, you don't incur a conversion fee from Stripe.

Currency Settings Page

To start we needed a page where people could see the currencies they were actively supporting.
The key information listed here is whether or not the currency is visible, which currency is the default, the number of purchases that have been made in that currency, and the currency type.

Because people are locked into a currency, we didn't want them to get locked out of being able to make any future purchases. This means once you support a currency you cannot stop supporting it, and everything you sell needs to be available in that currency. However, we can allow people to say "No one else will see that currency" and make it hidden to anyone who has not yet made a purchase.

The default currency is what we use to display the overall income in analytics. By keeping track of the conversion at the time of purchase we can show someone a single number as to how much they made that year.

If no purchases have been made we can still allow someone to delete a currency, so we need to give people visibility into how many purchases had been made in that currency.

Finally, it's helpful to know whether or not you are incurring conversion fees by supporting a currency and can set up bank accounts if a particular currency is popular but not yet linked to a bank account.

Add a Currency

When selecting a currency, we allow people to select from any option Stripe allows given the country they are in.
We highlight the conversion rate from their current default currency so they know roughly how much plans should cost.

If the currency they choose is a Settlement currency, we allow them to open Stripe in a new tab to set up a bank account in that currency.
In order to support a currency, every existing plan needs to have a price in the new currency. We could not be responsible for adjusting the prices given global conversion rates changing, and so people needed to manually add a price for every plan.

However, we could offer them a one time conversion that would auto fill the options with the day's current conversion rate.

Once filled in, the user could finish adding the currency and confirm that they knew these prices could not be changed and are not auto updating with fluctuating conversion rates.

Creating a New Plan

Once you have added a new currency, the next time you create a Web plan you'll be able to input a price for the new currency, along with all currencies you actively support.

Member Purchase

After adding a new currency a Host can sit back and relax as members are able to choose the currency they want to purchase in via a drop down on any page where a price appears.

Results

I worked with one other designer on these flows, digging into each error state and complication. I also acted as the Product Manager, and broke down the project into stages. I worked with developers to create jira tickets for shippable parts and managed the team up through the Handling Android stage which we completed in May 2021.

I then moved to another team that needed a designer more urgently and handed off the project to a new Product Manager who took the original designs to completion in September 2021.

Following the release...

58 Networks Operated in Multiple Currency in the first 12 hours

Given the numbers of networks asking for this feature, getting nearly 60 networks setup and already selling plans overnight was a huge success.

10% Of All Networks Collecting Payments Now Operate In Multiple Currencies

Improving the experience of 10% of all networks with plans is a major improvement and helps us draw in significantly more income.

25% Of All One Time Purchases In December 2021 Were Not In USD

After running for several months, the number of plans sold in other countries continues to grow with Euros and Pounds drawing in the most sales.

The Future

While I cannot disclose what projects are coming next, I can say the work we did here was very intentional to make sure we didn't block ourselves from being able to tackle another two years worth of projects that I helped design and lay out a path for, all with the goal of fixing our member onboarding experience.
HomeAll ProjectsConnect
jwelch2017@gmail.com6505751238LinkedInInstagram
Home
Projects
Connect