882321 - Send just one currency and required payment types to Bango in CreateBillingConfiguration

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Payments/Refunds, defect, P2)

Description

[Andy McKay]

When Mozilla calls Bango it calls it with the pay tiers, being the prices in various currencies. Unfortunately currency won't be unique, because the price tier information might be different for different currencies in different regions.

For example Seahorse uses USD. However it doesn't do carrier billing and there's no guarantee that the price is the same in USD as say the US or any other country.

The same might be true in the EU, where multiple countries use the EU, but VAT rates and other things may vary.

Price tiers on the marketplace will contain:

- region
- currency
- carrier
- methods (operator, card)
- price

I think we should pass more than just currency and price to bango so it can make a determination of what to use. I think we should also pass the region. So Bango can distinguish between Seahorse USD and US USD.

Comment 1

[Kumar McMillan [:kumar]]

Keir, what will it take to adjust the array of price in the Billing Config to accept a region parameter? Right now we have a fragile workaround to prevent duplicate currency/price combos: bug 882183. If we don't put a real fix in soon, it may start to charge people the wrong price unexpectedly.

Comment 2

[Andy McKay]

Moving up P1, I think this is a blocker for another reason: the payment type.

If we look at tier 20 on the marketplace:

http://metaplace.paas.allizom.org/tiers/dev/

This price tier will be paid for by carrier billing or credit card in some countries. And only by credit card in others.

Yet looking at the BillingConfigurationAPI docs we get to send in one payment typeFilter "String array of allowed payment method types" for the entire tier.

We need to be able to send in different types along with the region and currency.

Comment 4

[David Bialer [:dbialer]]

That is an issue, but not yet a big issue.  As prices in a specific currency, regardless of region or carrier, are the same - and we hope to keep it so.  I think we should, for now, keep all Price Points in a specific currency, no matter the carrier or country, the same across the world for that currency.   

The only issue is how VAT is handled, which varies across currencies.  Some are inclusive and some exclusive, and different rates are used in determining the price point.  But I don't think we need to worry too much about that as the end user price would be the end user price for a specific currency, and how taxes are handled may be complex, but not an end user concern.

Comment 5

[Kumar McMillan [:kumar]]

David, you say it's not yet an issue but how would we be able to tell Bango to process price point 20? As the table shows, Columbia and Venezuela can only accept cc payments (unlike the US) -- we have no way to give Bango a typeFilter based on region

Comment 6

[Andy McKay]

I think we need to be passing something like this through to Bango. Forgive my bad JSON and made up values. This allows to specify the region, carrier, the payment methods for that region and the different prices for combination.

{
  'region': 'PLN',
  'carrier': 'DT',
  'methods': {
    'card': {
      'currency': 'EUR',
      'amount': '1.99',
    },
    'carrier': {
      'currency': 'PLN',
      'amount': '4.99'
    }
},
{
  'region': 'Canada the great',
  'carrier': 'Telus',
  'methods': {
    'card': {
      'currency': 'USD',
      'amount': '3.99',
    }
}

Comment 7

[David Bialer [:dbialer]]

I suggested a locale like structure in webdev a few weeks ago.
Your proposal is similar.  My assumption was that we were passing price points though not currency, and didn't take into account payment methods.

It was:
I would like to propose an extension to payment JWT to be able to support more flexible pricing by country, carrier, and payment method.

something like below:


pricePoint: 1,
  localPricePoints: {
    venezuela: {pricePoint: 10}
  }



.. to say: use price point 1 everywhere except for in Venezuela use price point 10.

The case of needing to price differently between carriers within a region has not yet occurred.  But planning for it, we could expand as follow.

pricePoint: 1,
localPricePoints: {
  venezuela: {
    carriers: {
    "*": {pricePoint: 10},
    movistar: {pricePoint: 5}
    }
  }
}

Comment 8

[Kumar McMillan [:kumar]]

David, this is not the JWT format that in-app payment developers will declare. This is an internal declaration of all possible prices/currencies/methods per region that we will pass internally from Mozilla to Bango

Comment 9

[Caitlin Galimidi [:c8o]]

Team - 
This is a wontfix for launch.

Needs to be discussed with product management at Mozilla and Bango as new requirement for the next version. This would be a fundamental change to Bango's platform and would impact *all* their partners, not just us. 

David can we add this to the discussion for v2

Comment 10

[Andy McKay]

I'm unclear how we are meant to complete v1 then. Is there a workaround I should user?

Comment 11

[Kumar McMillan [:kumar]]

We discussed a more short term fix to the Seville issue in bug 883936

Comment 12

[Andy McKay]

Dropping priority since we've got a workaround for the moment.

Comment 13

[Andy McKay]

This will become a blocker for Hanger.

Comment 14

[Andy McKay]

(In reply to Andy McKay [:andym] from comment #13)
> This will become a blocker for Hanger.

Apparently this is not the case.

Comment 15

[Andy McKay]

After chatting to Bango, I think we should work with Bango to create a new API for this. I will get this started from Mozilla's end to create a first prototype of what the API should look like.

Comment 16

[Andy McKay]

Assigning to Jim for a scope change on Bango's side for the new api.

Comment 17

[Andy McKay]

After review, I think Keir is right, the BillingConfiguration will do most of this already.

In a world where Mozilla does payment choice and calculates:
- what region the user is in
- what method the user wants to pay by

This becomes a very simple call to Bango. For example if we've found that a user want's to pay by credit card, they are in Poland we send:

priceList: [[1.99, 'EUR'],], typeFilter: ['CARD']

If they are in Poland, but want to pay by carrier billing, we'll send through:

priceList: [[3.99, 'ZLN'],], typeFilter: ['OPERATOR']

We've adjusted the price to be the correct one for card or carrier billing in the scenario where the credit card price is different from carrier billing price.


Problems:

- in this scenario Bango must accept that we've got the right price and it matches up with the Bango price tiers

- we've done the logic for figuring all this out, which means we've got a complete copy of the logic on our end and we have to keep it all in sync, but I don't think there's a way around that. If Bango has different logic, we'll get errors.

- if the header enrichment or MT auth gives different values from our mcc and mnc, we'll get an error because the logic might result in a different price.

- Bango will need to change their screens to use the choices we provide for payment method types appropriately.

- its not obvious how we'll send through different prices for carrier billing or credit card. Perhaps we should limit ourselves to only ever selecting one payment method, if they don't want to or can't use that payment method, they bounce back to mozilla and we try again with another method. For example, this doesn't make too much sense:

priceList: [[3.99, 'ZLN'],[1.99, 'EUR']], typeFilter: ['CARD', 'OPERATOR']

How does that sound, Keir, Kumar?

Comment 18

[Kumar McMillan [:kumar]]

This makes sense to me. In the case of a user *choosing* operator billing but Bango somehow falling back to operator billing this might be problematic too.

Comment 19

[Andy McKay]

Moving to be part of developer and payment choice.

Comment 20

[Andy McKay]

If MCC and MNC are detected and are part of a region supported by Bango, then:

* send carrier billing as a payment choice as well as credit card otherwise
* just send credit card

When MCC and MNC are detected:

* send the correct currency and price from our table, instead of all of them

Comment 21

[Keir Kettle]

Mozilla need to pass MNC/MCC in Billing Configuration and Bango need to make use of it

Comment 22

[Keir Kettle]

Bango need to create a new Billing Configuration option for MNC/MCC, Steve mentioned there was potentially another value that could be used to further identify MNVOs - we should also add a BCID option for this.

Comment 23

[Andy McKay]

Summary of conversation on site. Bango will do a new version of Billing Configuration that will do the following:

* add mcc and mnc to the API
* add region to the API
* add in key value mapping of price lists something like: {'card': [[1.99, 'USD'],], 'operator': [[1600, 'COP'],]}
* typeFilter will likely be removed

Marketplace will pass through the mcc, mnc and region, if available. If none of those are set, we are in "rest of the world" and for the moment that's not supported for payments and we'll fail on the marketplace end.

Comment 24

[Maria.Vidondo]

Santi to review the most efficient way of passing the MNC/MCC Information and to feedback within the next couple of weeks.