900253 - Improve bango signup page

Status: RESOLVED WONTFIX

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

Description

[Kumar McMillan [:kumar]]

A French developer (for FoxyMPD app) reported that he could not enter bank account details for an app. His account consists of a SWIFT number and an IBAN number.

This bug is to:
1) verify what happens when the user leaves Bank Account Number blank and enters the SWIFT in Bank Account Code. Is it an error? Is it successful?
2) if #1 works, make the form more intuitive
3) if #1 does not work, let's support bankAccountIban in the payment form. The Mozilla Exporter already supports this optional field, as does Solitude. The Mozilla Exporter docs say that SWIFT numbers go in bankAccountCode.

See also: https://wiki.mozilla.org/Apps/ID_and_Payments#Mozilla_Exporter_API

Comment 1

[Andrew Williamson [:eviljeff]]

btw, the SWIFT code is an institution (e.g Bank branch) identifier so needs further account details to identify the actual account.  IBAN is a single code that uniquely identifies the country+bank+branch+account.  Generally you wouldn't need the SWIFT code if you had the IBAN.

Comment 2

[rodrigue.villetard]

Hi,

The thing is that french IBAN is 27 chars long, the form accept 20 chars max.:


“Ensure this value has at most 20 characters (it has 27).” Form error message. 



Many countries seem to have an IBAN longer than 20. (see https://en.wikipedia.org/wiki/International_Bank_Account_Number#IBAN_formats_by_country)


cheers,
Rodrigue

Comment 3

[Kumar McMillan [:kumar]]

ok, thanks for the info. We need to adjust the form. This is fully supported by Bango's API we just don't have it hooked up. I'm bumping the priority since we shouldn't block European developers from setting up payments.

Comment 4

[Fred Wenzel [:wenzel]]

Up to 34 characters are valid, btw.

Comment 5

[Kumar McMillan [:kumar]]

Bram, is the UX something you could take a stab at here? I guess we'll need two stories:

- a developer who has a bank account matching the current form
- a different developer who has a SWIFT/IBAN account

Comment 6

[Bram Pitoyo [:bram]]

Yes, I’ll design something for this scenario. My bet is that we will only need a simple tweak to the existing design.

Comment 8

[Andy McKay]

See also bug 886931 which covers the same thing and the comments from the same developer. In fact I'll dupe that to this :)

Comment 9

[Bram Pitoyo [:bram]]

Attachment: add a new payment account - 01

Attached is the mockup of an add a new payment account user interface that takes the strategies below into account.

STRATEGY 1
----------
Foolproof our UI as much as possible, so the chance of entering the wrong information is minimized.

* Country selection will determine whether IBAN or a normal account number is relevant (certain countries use IBAN and others don’t)
* Country selection will determine whether VAT number need to be filled in (if country selected is located in Eurozone, VAT is relevant)
* It’s impossible to input a bank address outside of the selected country


STRATEGY 2
----------
Build our own or link to third-party validation tools and resources, so user is more confident.

* How to read a check to find an account number (http://ygraph.com/graphs/howtoreadacheck-20121208T051645-7ptd78l.jpeg)
* Which country, bank/branch and account number is associated with an IBAN? (http://auctionfeecalculator.com/iban-transfers.html)
* What is a SWIFT code, and where to find it (http://www.theswiftcodes.com/)


THE FUTURE IS AUTOFILL
----------------------
A lot of information can be derived from SWIFT codes. When autofilled onto the form, we can minimize developer’s work and ensure that the inputted information is always correct every single time: a big win.

* Inputted SWIFT code is matched against a database of bank/branch name that exists on www.swift.com/bsl (for example, try doing a search for the BIC “CENAIDJA”)
* City, Address and Zip code values can be derived from each branch info page (http://www.thebankcodes.com/swift_code/r.php?cs=y&cv=PORTLAND%2COR)
* These values will auto-populate the form

Even though Bango doesn’t validate information on their end, if we can make sure that the information that we give them is already correct, developers will always be able to receive their payment.

Comment 10

[Andrew Williamson [:eviljeff]]

Nice work Bram.

Some comments:
Afaik IBAN uniquely identifies an account - you don't actually need SWIFT as well if you have IBAN (but I don't know of a reverse lookup service to get the bank address, etc, without SWIFT)

some BIC/SWIFT codes are for the head office of the bank rather than the branch (mine, for example) so the lookup isn't 100% reliable.

Eurozone != EU - i.e. VAT is a EU thing rather than a Eurozone thing so countries like the UK that are in the EU, but not the Eurozone, also use VAT.  (its actually more complicated than that http://en.wikipedia.org/wiki/European_Union_VAT_area#EU_VAT_area but we can probably ignore the small islands and overseas territories that are the exceptions)

Comment 11

[Kumar McMillan [:kumar]]

This looks great. Some notes:
- In the US, the SWIFT field should be optional (I think it's rare but some banks support it) 
- For the US we need a Routing Code field which is the most common case. This is just a labeling difference but I think it's important because people in the US won't know what SWIFT is.
- In the UK, don't we need an optional VAT field?
- I wonder if we need an "I'll do it myself" button that lets a user optionally input all possible fields: account number, account code (which could be anything), and IBAN? Some future thinking US banks may support IBAN.

Comment 12

[Andrew Williamson [:eviljeff]]

(In reply to Kumar McMillan [:kumar] from comment #11)
> - In the UK, don't we need an optional VAT field?

Btw, being VAT registered is optional in all EU member states, if the business's income is less than a certain threshold (£77,000 in the UK, for example).  So the field should be optional for all EU countries.

Comment 13

[Bram Pitoyo [:bram]]

The ideas above sounds good. To summarize:

1. VAT should show up in all EU countries (including the UK), but marked as optional. However, do we need to explain these things, or is it too much?
   * Why you may or may not need one
   * How to get one if you do need one
   * What are consequences of not having one

2. If having an IBAN means that user don’t need SWIFT, can we make SWIFT optional? From reading the documentation, I tend not to think so. But if we can, then let’s do it.
   * Yet, if filling in SWIFT means that user don’t have to fill in and worry about the accuracy of an address, it might result in a big overall time saved

3. In the US, should we replace the “SWIFT” form field label with “routing number”? Or even replace it with “SWIFT/routing number” to be inclusive?

4. Having an “Advanced mode” where we show all possible fields might be helpful to a certain subset of users. We can add it as a small link on top of the interface.

Comment 14

[Andrew Williamson [:eviljeff]]

(In reply to Bram Pitoyo [:bram] from comment #13)
> The ideas above sounds good. To summarize:
> 
> 1. VAT should show up in all EU countries (including the UK), but marked as
> optional. However, do we need to explain these things, or is it too much?
>    * Why you may or may not need one
>    * How to get one if you do need one
>    * What are consequences of not having one

I think if its marked as optional users will just ignore it if they don't have one so we're okay to leave it at that.

> 2. If having an IBAN means that user don’t need SWIFT, can we make SWIFT
> optional? From reading the documentation, I tend not to think so. But if we
> can, then let’s do it.
>    * Yet, if filling in SWIFT means that user don’t have to fill in and
> worry about the accuracy of an address, it might result in a big overall
> time saved

From further reading it seems that a lot of transactions (within the EU) require SWIFT/BIC and IBAN so it might be safer to require both.  Note that for many banks (in the UK at least) only seem to have one SWIFT code, for the head office, so pre-filling the address is only partially useful if we're expecting the branch address on the form.  Does Bango have guidelines about this?

Comment 15

[Bram Pitoyo [:bram]]

(In reply to Andrew Williamson [:eviljeff] from comment #14)
> for many banks (in the UK at least) only seem to have one SWIFT code, for
> the head office, so pre-filling the address is only partially useful if
> we're expecting the branch address on the form.

The documentation requires “The main address line of the bank at which the account is held”. So, for better or worse, they require the branch address.

Deriving address from SWIFT isn’t hard, if we have the a database of worldwide branch database and a mean of constantly updating it.

Comment 16

[Andrew Williamson [:eviljeff]]

fwiw, part of the UK IBAN is the Bank and branch code (aka sort code)
[GBkk bbbb ssss sscc cccc cc] and the ssssss can be resolved to the actual branch address (https://www.bindb.com/sort-codes.html)

Comment 17

[Andrew Williamson [:eviljeff]]

Bram, is UX done on this and its ready for implementation (as far as you're concerned)?

Comment 18

[Bram Pitoyo [:bram]]

(In reply to Andrew Williamson [:eviljeff] from comment #17)
> Bram, is UX done on this and its ready for implementation […] ?

Yes. The UX is ready for implementation, although, contrary to the mockup, VAT should be shown when UK is selected.

Comment 19

[Andy McKay]

Did a quick incremental improvement, just to make it clearer.

https://github.com/mozilla/zamboni/commit/e12249

Keeping this open for a fuller implementation (and dropping it down from a P1 as a result)

Comment 21

[David Bialer [:dbialer]]

Brilliant! - how does Bram always stay 2 steps ahead of me?
Can we add to this bug a developer feedback mechanism - that their account info is accepted or there is a problem.  Do they receive a confirmation email saying they are set up?  There is so much opportunity for user error on many of the fields that are not validated.

Comment 22

[Bram Pitoyo [:bram]]

(In reply to David Bialer [:dbialer] from comment #21)
> There is so much opportunity for user error
> on many of the fields that are not validated.

Thanks, David! I’d like to take the opportunity to again push the idea of bank account validation. It would be great if we could prevent developers from committing clerical error — not so much in terms of mistyping account number, but mistyping addresses that can vary widely depending on country and locality. I am not exactly clear if we can do verification at this level, but whatever we can do to make sure that developers get payout at the right time would contribute to a good user experience.

Note, for example, how Bango currently cannot alert developers when their inputted account information is incorrect. Nor can developers correct their information in an online form (ie. they have to send an email, requesting manual change). The only way that developers will realize their mistakes is when no money is deposited into their bank account when it’s supposed to.

Comment 23

[jocull]

Just want to chime in here and add my 2 cents.

Our U.S. bank is small and local. Swift codes aren't an option, as they must route all international transfers through a 3rd party, there's fees associated, and I'm pretty sure it would simply get lost as the account number we give and the Swift code from the 3rd party do not align.

Our only option is to use an account number and routing number, as we would anywhere else. I heard rumors of supporting PayPal - I would agree with this as a stopgap, but am slightly concerned about fraud claims and digital goods. We've been screwed over by that before.

Comment 24

[Andy McKay]

We've got the improved page with the link to the detailed MDN documentation at the top now.