Simple open payments guide #59
Conversation
| - Ensuring all parties agree on the final amount after any fees are added to a transaction. | ||
| - Determining the best underlying method to use for the transaction. | ||
|
|
||
| With the Open Payments standard, applications do not need to be registered financial service providers (FSPs) to facilitate transactions. Instead of moving or holding money, applications send payment obligations. This means they are not transferring money directly but are sending instructions to your financial institution to transfer the funds on your behalf. This setup eliminates the need for the application to be a financial service provider itself, even though it has direct communication access to your account. This is beneficial for applications because they don’t need to contend with the legal and compliance hurdles required to be a financial services provider. But it’s also advantageous for you because you don't need to share sensitive information with online applications. Applications storing information like credit card numbers and CVV codes always pose a risk of data leaks or hacking, even with the best intentions. |
There was a problem hiding this comment.
"But it’s also advantageous for you because you don't need to share sensitive information with online applications"
This is just a thought I had (especially knowing the banking context in Canada/North America), but we could also mention that without any API standards, some third-party apps like budget trackers rely on web-scraping to actually connect your bank accounts, meaning they end up knowing your banking login details too.
|
|
||
| An alternative is for applications to integrate directly with their bank's payment processing services. This method can offer lower transaction fees and increase control over the payment process. However, it requires significant development effort and is not always possible. Additionally, switching to a different bank becomes very challenging due to the extensive integration work that was already completed. | ||
|
|
||
| This problem gets even more complicated when we consider situations where either the sender or the recipient of funds does not have a bank account. What if a payment has to take place between a bank and a mobile money provider? Now the application would have to also integrate with the mobile money provider. Custom integration becomes an expansive problem. |
There was a problem hiding this comment.
I think "receiving bank" can be removed here, given the paragraph talks about the challenge of moving money between a sending bank directly to a mobile money provider
There was a problem hiding this comment.
@mkurapov my idea here was that the fundraising app did a direct integration with their bank (where they'd like to receive funds). Now the sender has a bank, that's fine because bank A can probably talk to bank B. But if the sender has a mobile money account or digital wallet we may have issues.
There was a problem hiding this comment.
@JoblersTune makes sense, in that case, maybe we can just rename from "receiving" to "merchant" bank maybe (or "fundraisers" bank), and then "customer" bank? To remove any confusion from sending/receiving
Co-authored-by: Max Kurapov <maxkurapov@gmail.com>
Co-authored-by: Max Kurapov <maxkurapov@gmail.com>
|
Last outstanding items:
|
|
|
||
| Currently, the adoption of the Open Payments standard is still in progress. Some innovative institutions and services have begun to integrate this standard, but widespread use is still developing. | ||
|
|
||
| [GateHub](https://gatehub.net/) is a digital wallet provider working with the Open Payments standard globally. They are able to facilitate some cross-currency transactions, although regulatory limitations may apply depending on the user's country of residence. The [Fynbos Wallet](https://wallet.fynbos.app) is another example. They are operational in America, Europe, and South Africa. However, transactions are currently limited to other Fynbos users within the same region due to regulatory and technical constraints. There are plans underway to create payment channels between Fybos and GateHub users in Europe. |
There was a problem hiding this comment.
"There are plans underway to create payment channels between Fybos and GateHub users in Europe."
I think not just Europe but all Gatehub to all Fynbos users. But they may start with Europe.
There was a problem hiding this comment.
Since this is an OP intro I'm hesitant to sidetrack too much on making this a progress report and map of future developments.
We could try, "Chimoney and Fynbos digital wallets have also implemented Open Payments capabilities. Chimoney enables Open Payments transfers between Chimoney accounts, and Fynbos supports payments between Fynbos accounts. Fynbos is operational in America, Europe, and South Africa. However, Fynbos transactions are currently limited to wallets in the same region due to regulatory and technical constraints. Plans are underway to establish payment channels between Fynbos and GateHub users, beginning with Europe soon."
| ## TLDR | ||
|
|
||
| Standardization enhances interoperability by reducing the development effort required for each integration. This alone brings down costs while providing a scalable and efficient solution for handling digital payments. When interoperability is easy, there is no need for unnecessary middlemen and the fees they add to the cost of transactions. | ||
|
|
||
| With Open Payments, users are empowered to give applications direct access to their accounts, deciding who can access their money, how much, and how often. Users only share public information (in the form of wallet addresses) with applications when making payments, keeping their sensitive financial data private. | ||
|
|
||
| Applications can handle payments without needing to be registered financial service providers or navigating the risks involved in handling sensitive information like credit card numbers. |
There was a problem hiding this comment.
Should we move that to the top to be an actual TLDR?
There was a problem hiding this comment.
What if we change the name to "Key Takeaways" instead.
My reluctance with moving it to the top is that I want to create a gentle path through the post that encourages an incremental introduction to the concepts. I worry it's kind off putting to put the summary at the top. People who are less technical might feel like this article is pitched over their heads. But by the time they reach the bottom they should understand all of this and it just re-captures the main points to give a simple summary of what OP is.
What do you think?
Writing a blog post to inform people who are not necessarily very technical about Open Payments. Or as a starting point for technical people before they dive into the deeper stuff and the docs.
Initial thoughts: