View Revisions: Issue #5207

Summary 0005207: offer high-level merchant integration in addition to the current low-level integration
Revision 2017-12-09 22:15 by Florian Dold
Description Currently offering payments with Taler is not as easy as it could be (and not as easy as with some other payment providers). We need to set headers, implement quite a lot of endpoints and know too many details of how the protocol works.

This is fine for our demos, but we could make it even easier, by offering a merchant-as-a-service component that takes over some duties that currently the frontend has to do.

It would offer mostly just two end-points:
1) create an order: returns an order_id and a URL that's served by the merchant-as-a-service component which will trigger the payment and take care of all the details (headers, contract generation, etc.)
2) check if an offer_id has been paid for, returns the contract terms and either "yes" or the URL to redirect the user to that will make the payment happen

Additionally we can allow payments even on *static* websites, by POSTing a form to the merchant-as-a-service component. This is useful either for donations or for products that will be physically/individually be delivered. If the seller runs out of stock, they can give a refund in the web interface.

The difference to the "low-level integration" that we currently have is that the merchant-as-a-service serves pages to the browser and the wallet directly.
Revision 2017-12-09 22:14 by Florian Dold
Description Currently offering payments with the Taler is not as easy as it could be (and not as easy as with some other payment providers). We need to set headers, implement quite a lot of endpoints and know too many details of how the protocol works.

This is fine for our demos, but we could make it even easier, by offering a merchant-as-a-service component that takes over some duties that currently the frontend has to do.

It would offer mostly just two end-points:
1) create an order: returns an order_id and a URL that's served by the merchant-as-a-service component which will trigger the payment and take care of all the details (headers, contract generation, etc.)
2) check if an offer_id has been paid for, returns the contract terms and either "yes" or the URL to redirect the user to that will make the payment happen

Additionally we can allow payments even on *static* websites, by POSTing a form to the merchant-as-a-service component. This is useful either for donations or for products that will be physically/individually be delivered. If the seller runs out of stock, they can give a refund in the web interface.

The difference to the "low-level integration" that we currently have is that the merchant-as-a-service serves pages to the browser and the wallet directly.