Find a dedicated contributor for payment methods

[chimp1984]

We should find more secure and convenient payment methods to allow higher trade amounts and increase trade volume. There are often very local payment methods only used in 1 country of a small reagion. It is hard for Bisq contributors to investigate as you usually need to have a bank account there to use it and get a clear understanding how it works and how are the chargeback risks. I think we should have a dedicated role for payment methods, but the concrete investigation and research need to be done by local people. Similar to translations. The duty of the role owner would be to be the driver and push progress in that area and find local people who provide the research. I think the research need to be paid like a bounty.

[MwithM]

The most important requirement for this role is that it should be able to implement new payment methods. Now there's a few colombian payment methods that, althought there haven't been any security concerns, have not been implemented.
If new payment methods are implemented in an agile way, it's more probable that we get new suggestions.

[sqrrm]

The implementation part of this work is likely not the problem. It's quite easy to implement, as long as you know what the requirements are. As @chimp1984 mentions, it's hard to get good information on local payments methods.

[sqrrm]

In particular I feel it could be worth focusing on countries such as Turkey and Lebanon. The problem is the same though, we need someone local to do the research on particular payment methods.

[chimp1984]

@MwithM Yes as @sqrrm stated the role does not require dev skills. A standard payment methods is implemented in 1 hour by a dev. Whats usually caused the friction is that nobody writes up a clear and complete spec (which data are required, is anything special) and clearify the chargeback risk. So I see the role like the transifex admin role, someone who drives and manages. Local contributors provide the specs and info. The role owner verifies if that meets our requirements and if so pings the dev team that some dev pick it up.

[chimp1984]

@MwithM If you would be available for that role, would be great! Transferwise would be a prime candidate but requires more research...

[MwithM]

Whats usually caused the friction is that nobody writes up a clear and complete spec (which data are required, is anything special) and clearify the chargeback risk.

Maybe we just need to specify this needs (at something like https://bisq.wiki/Request_New_Payment_Methods) and make Growth team responsible of research people with feet on the ground, necessary data, attending the requests and contacting with devs when previous process is complete to proceed to implement this payment method.
What I mean is that I think that the needs of this role aren't so specific that, without proper guidance, anyone at Growth or Support could proceed take the tasks that a Payment Methods Maintainer should have. From growth we could develop bounties for unknown regions, just like we did for market makers.

[chimp1984]

I don't mind if its done by growth team, but we need someone who feels responsible for it an drives it. It is one avenue how to increase fiat volume by finding safe payment mehtods with no limit requirements. As well as to benefit from multicurrency methods to merge markets.

[pazza83]

I would be happy to contribute to this. I could start with investigating issue #243

I think multi-currency accounts like TransferWise have lots of potential. Revolut, similar in some ways to TransferWise is consistently number 2 in amounts of completed trades per week.

[chimp1984]

That would be great! Thanks for your initiative!

[initCCG]

It seems best to us to simplify the whole system to one generic "Online Payment System" type, the way HodlHodl does.
(There, the user can propose the particular system to the admin and have it added as an option within an hour or two. Here, it would go in the next release.)
The system name should be added to the drop-down, based on a list of standard characteristics, such as ability to charge back, etc.

Most if not all of these systems in our regions require just the user's name and account or phone number as inputs - usually the phone number is the account number. So, those 3 generic input fields - with perhaps a 4th blank for "Extra info" - would cover the majority of such systems worldwide.
The nickname of it would already be covered in account creation.

[chimp1984]

Thanks @pazza83 for taking that role!