Propose API for B2C payments and withdrawals

[hashmap]

Currently we are more oriented to peer-to-peer payments even if we support http client/server interaction.
We may want a standardize API for B2C (Business to Customer) case which has the following properties:

• Business is publicly available and can launch a listening socket on some port.
• Customer can be behind NAT and can only initiate connections.
• Customer can initiate payment
• Customer can initiate withdrawal

We need this API be implemented in the wallet(s), server side will be specific to particular service, because it includes custom logic like customer balance checking, updating internal balance etc.

It would greatly improve user experience by enabling one-click (one command if you want) payments and withdrawals from any service which supports this API.

[antiochp]

User initiated withdrawal is potentially scary.

[hashmap]

@antiochp why? it's how many exchanges and pools work now, unfortunately this interaction is not standardized yet

[antiochp]

Just if its via an https endpoint then you are hitting an API that basically spits funds out to anybody who asks for them if we're not careful.

[garyyu]

It would greatly improve user experience by enabling one-click (one command if you want) payments and withdrawals from any service which supports this API.

@hashmap I had same thought before, and I hesitated for same comment as @antiochp 's: User initiated withdrawal is potentially scary.

But I think it's still possible to give a safe design to implement this "one-click" idea. So I second you.

Considering the current exchanges withdraw process, they normally ask for 2 or 3 steps authentication for each withdrawing:

1. password / dedicated withdraw password
2. six digits google authenticator / sms
3. six digits email authentication code

So, we can think all these 2 / 3 authentication steps as a mandatory condition for our new "one-click" solution. For example, "one-click withdraw" API provide additional message signature and ask for 2/3 steps authentication.

I will give more detail on this for further discussion on design.

[antiochp]

To be clear - not opposed to this, just something that we'd want to think through carefully (obviously).

👍

[JacobPlaster]

+1 on this feature. It would be great for us to use

[GlobalSG]

this is what we need for Grin