Random question here.
Is it possible to build a payment gateway between peers over holochain and holo that accepts VISA, Mastercard, etc?
A bit of research and I found this in the forum.
So basically it May be possible to have a payment gateway by having it on the front-end instead of the back-end. But it’s gonna be hard since a traditional payment gateway needs a server to operate and meanwhile holochain is a P2P framework.
But still, that reply was 2 years ago. Perhaps I can see some updates regarding this matter?
My understanding is there is no barrier to combining traditional server gateway to your p2p holochain app. You can do that if you want. Here is a timestamped clip of Arther Brock answering a question from someone at Dada about using Visa as a more accessible onramp for their users: https://youtu.be/Q26zJeISgog?t=1577
1 Like
I see, is it possible to make a payment gateway somewhat distributed in the future?
What do you mean exactly with a payment gateway between peers? As in, should the payment with credit card go both ways, so we can pay each other? Or a single way, like a user pays for a subscription for a service?
I don’t know the solution, but I am also interested in learning the best ways to enable this, especially the later.
This will always be a bit of a challenge because the world’s payment systems are so heavily regulated (and hence centralised).
Authorize.net, Stripe, and friends will let any HTTP client (including your browser) do things through their API, so you could theoretically build payment processing into the UI and record a source chain entry that gives proof that the payment gateway processed your payment. The tricky thing is that these gateway APIs require a valid merchant key. So whoever wants to receive that payment – the merchant – has to give you their keys, which means you have all the powers the merchant has. Not to mention that anyone who wants to receive money will have to get a merchant account, which starts at $30/month and goes way up from there. (I’ve looked into some of the payment processors’ APIs; there’s no way to hand out one-time API keys for a single payment.)
So I think that forces you to design a solution that doesn’t require a merchant at all – like PayPal or Venmo – or have a single peer, with a merchant account, operating a gateway for payment processing. I think we’re doing that with Holo, though i don’t think it’ll be for credit cards, at least not at first. It’ll just be a crypto gateway. That’s an option worth considering though – a mashup of BerkShares and mutual credit. Anyone wanting to load up their account, or cash out for ‘actual’ money, would have to go through the gateway peer.
I like this idea and this could work in a lot of scenarios/networks, especially in social p2p spaces.
What if I wanted to sell 200 user subscriptions to a corporate client. In that case, the above solution wouldn’t work well since every agent (employee) would need to take responsibility for their own subscription.
In the above case, would it make sense to set up a centralized server that handles the recurring payment and management of access tokens for each employee? The UI can easily check if the token is valid and return the network UID. On every startup, the UI can check if the token is still valid (or active). This could impose some security risks and the service could easily become a honeypot for hackers. Not sure if I am missing something and if this is a valid solution for the use case. Would be cool tho…
I think so, yeah. In that case you already have a centralised point of administration, so it would make sense for them to collect the fees, then issue certificates (entries on their source chain) that give proof of payment. I think a headless Holochain node that connects directly to a payment gateway would make the most sense there.
What I can’t quite picture, yet, is how to bar access when the subscription hasn’t been paid. In the future, the standard way of booting someone out of a DHT will be to issue a ‘delete’ action against their agent ID. The headless admin node could perform that action every night or something. Then all the peers will eventually stop talking to them.
My concern is that a ‘delete’ action is what’s called a ‘tombstone’; once it’s applied, it can’t be un-applied. If you’re simply late by a few days, what happens then? Once you pay, you won’t be able to get back in again.
I honestly don’t know if I’m right about these details; maybe there’s more to learn about the dev team’s plans for how to remove someone from a DHT.
1 Like
Interesting and not sure what the solution would be. In the corporate plan/subscription use case, not paying could mean that nobody would have access to the hApp. Kind of like how a traditional subscription works. You wouldn’t delete or ‘tombstone’ anyone, in this case. The network just becomes inaccessible for everyone. When an employee leaves and you want to boot that person from the DHT, maybe each agent needs to call an endpoint that returns hashes to delete from the DHT? Not sure if and how this could work…
My main concerns is calling endpoints from the UI, since this could easily be ‘hacked’. A more secure way would be to call these ‘outside/external endpoints’ from the DNA. And if the centralized endpoint is responsible for storing/providing the network UID’s, this could become very dangerous. You don’t want anyone to know other organisations UID’s and eve-drop on, let’s say, internal reviews or processes/comms. But there could be some solutions to add security, maybe add passwords or IP whitelisting.
I would like to learn more about headless Holochain, especially how this would work on Holo and how to store the merchant key in a safe way. It would be cool to build the whole public-facing website + administration and serve this through Holo. Probably, I am still thinking too much in the old/traditional way 
EDIT: Maybe an even easier; safer and less strict solution, when dealing with corporates subscriptions, would be to just do manual invoicing and the handing out of network UID’s. I can imagine centralized storing of UID’s is bad practice and can be very dangerous.
Could capability grants be a useful tool here for managing subscriptions?
1 Like
I don’t understand capability grants enough. What I do know, is that a lot of corporates (Insurance) use centralized ‘water cooler’ or ‘pulsing’ kinds of apps, which are centralized and in the market for a long time. The features that Holochain provide (out of the box) are very attractive and sellable. This could become a feedback loop.
EDIT: There are ‘employee rewarding systems’ out there, that are centralized and are currencies, essentially. Make DAO’s from the inside-out…
EdIT2: It is very difficult to look from outside in. Even harder to do system change. I would recommend to look for things you are part of and where p2p could shine. Even if you have less experience, you can always introduce stuff…
1 Like