Closed Bug 882321 Opened 9 years ago Closed 7 years ago

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

Categories

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

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: andy+bugzilla, Assigned: santi)

References

Details

(Whiteboard: [bango-v2])

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.
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.
Assignee: nobody → keir
Priority: -- → P3
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.
Priority: P3 → P1
Severity: normal → blocker
Duplicate of this bug: 881851
Blocks: 882400
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.
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
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',
    }
}
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}
    }
  }
}
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
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
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
I'm unclear how we are meant to complete v1 then. Is there a workaround I should user?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
We discussed a more short term fix to the Seville issue in bug 883936
Dropping priority since we've got a workaround for the moment.
Severity: blocker → normal
Priority: P1 → P2
Summary: Sending region along with the currency → Send region to Bango with the currency/price
This will become a blocker for Hanger.
(In reply to Andy McKay [:andym] from comment #13)
> This will become a blocker for Hanger.

Apparently this is not the case.
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.
Assignee: keir → nobody
Depends on: 892068
Assigning to Jim for a scope change on Bango's side for the new api.
Assignee: nobody → Jim
Blocks: 858690
Assignee: Jim → amckay
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?
Flags: needinfo?(kumar.mcmillan)
Flags: needinfo?(keir)
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.
Flags: needinfo?(kumar.mcmillan)
Moving to be part of developer and payment choice.
Assignee: amckay → nobody
Blocks: 963203
Blocks: 987661
No longer blocks: 963203
Summary: Send region to Bango with the currency/price → Send just one currency and required payment types to Bango in CreateBillingConfiguration
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
Depends on: 990007
No longer blocks: 987661
Assignee: nobody → keir
Flags: needinfo?(keir)
Mozilla need to pass MNC/MCC in Billing Configuration and Bango need to make use of it
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.
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.
Assignee: keir → santi
Santi to review the most efficient way of passing the MNC/MCC Information and to feedback within the next couple of weeks.
Status: REOPENED → RESOLVED
Closed: 9 years ago7 years ago
Resolution: --- → WONTFIX
Whiteboard: [bango-v2]
You need to log in before you can comment on or make changes to this bug.