Let’s consider a scenario where the vendor’s Infusionsoft is set in the local currency of NZD (New Zealand Dollar). However the vendor wants products and subscriptions in various currencies eg. NZD, EUR, GBP and USD where the payment method is PayPal.
How Multicurrency Works
Firstly, note that each Infusionsoft application only supports a single currency so all orders/invoice in Infusionsoft for this vendor will be in NZD.
What SubscriptionBoss does is allow payment to be taken in another currency but the order to be translated into NZD for Infusionsoft.
Custom fields in Infusionsoft are created to hold the original currency amount and the effective FX rate. SB will also calculate a notional FX loss/gain.
Benefits Of Multicurrency
What SB does is allow the client to pay in their local currency which is good for the client for several reasons:
- they do not get charged the 4% foreign exchange charge by PayPal to convert their currency to NZD
- they understand prices better in their own currency and hence are more likely to buy (true for some buyers)
- they like the fact that the supplier is selling to them in their own currency
Having a USD/AUD balances in their PayPal account is good for the vendor too if they have expenses (such as hosting for example) which can be paid directly from their USD/AUD PayPal account. This saves them 4% FX charges.
That is the upside.
Overheads Of Multicurrency
There is a downside too: a bit more administration and some custom development:
Extra Subscription Setup
The vendor needs to set up a subscription in SubscriptionBoss for each subscription/currency combination.
For this, there is a “clone subscription” feature so this should only take a few minutes as the NZD subscription can be cloned and then it is a simple matter of changing 4 fields:
- the currency,
- the initial amount,
- the recurring amount
- the description
Some Custom Development To Internationalize The Checkout Process
The checkout process needs to enable people to choose their currency or country. This needs some custom development.
The custom development can be trivial or significant depending on the vendor requirements.
The reason for this is there are several possible solutions depending on:
- the sales funnel
- whether potential buyers are registered as contacts prior to any sale
- whether the vendor is running an affiliate program and needs to handle cookies
- whether the sales funnel ends with an Infusionsoft hosted order forms
- whether the sales funnel ends with an Infusionsoft checkout/cart
- whether the sales funnel ends with a self-hosted order form
- whether the vendor takes payment with credit card as well as PayPal
- how many products the vendor wants to do this for
- whether the vendor is selling individual products or bundles of products
- whether the vendor has access to any programming resource
Simple Checkout Scenario
The simplest solution is one where a multi-stage sales funnel offers just payment via PayPal. It would operate as follows:
- Have the potential buyer register first – this allows their country and any affiliate cookie to be captured
- Direct them to a self hosted order page passing their contact id and country
- Install a snippet of custom code that uses the country to derive what currency to use and hence which SB subscription prices to show
- The buyer chooses a subscription and clicks the button to purchase
- SB will take the payment through PayPal in the ‘local currency’ and register the sale in Infusionsoft in NZD, run any actions sets required and send the buyer to a thank you page
Complex Development Scenario
At the other end of the scale would be using Javascript to customize a single Infusionsoft-hosted order form where the country or currency is not known in advance, and the order form offers several payment plans and payment by both credit card and PayPal.
Leave a Reply