Embedded payment widgets
Thomas Baekdal posted a great article we need to drastically simplify payments online that has received quite a bit of attention today.
His proposal is to use an iframe to a third party payment site similar to how Facebook embeds it’s widgets. This would allow you to pay very quickly as well as selectively share address, email etc. with the merchant.
We in the OpenTransact actually proposed something very similar last year at the Internet and Identity Workshop.
OpenTransact is a new very simple standard for performing amongst other things payments. It is designed to be extremely simple to use and embed. It is already being used in my startup PicoMoney as well as various other sites such as Austin Time Exchange.
OpenTransact allows anyone to create very simple payment links that we call TransferRequests. This allows you to format a link very easily and use it to accept payments.
Here is an example:
<a href="https://picomoney.com/picopoints?amount=2&to=pelle@stakeventures.com¬e=test%20payment">Pay me</a>
And here is the actual link:
Reading Thomas’ article I realized it would very simple to embed that same link in an iframe using an additional parameter display=embed. This embed parameter tells the payment provider to format the page in such as way that it would work well in an iframe.
<iframe src="https://picomoney.com/picopoints?display=embed&amount=2&to=pelle@stakeventures.com¬e=For%20testing&redirect_uri=http://payglo.be/2012/04/23/embedded-payment-widgets/" width="100%" height="60" style="border:1px solid #ddd;padding:1px"></iframe>
Here is how it would look
This shows the power of OpenTransact and also how we can really improve things a lot by thinking outside the normal credit card gateway approach.
5 Responses to “Embedded payment widgets”
Interesting! 
One thing, though. I don’t like the idea that the payment info and personal information is being sent as part of the URL. It would be easy for an attacker to modify it.
One important part of my concept is that the client is never exposed to product, payment, or personal information. And after the transaction, not even the merchant would have the data.
-
The to field just contains the payment email address for the merchant. You can also register an application and use an OAuth2 style client_id which hides all of that.
None of the personal information is necessarily shared with the merchant, unless they request it.
Product information can be added as a url using the for parameter. While we don’t specify what happens on the other side, we expect an RDF/microdata/OpenGraph kind of product meta data to be developed.
Finally the delivery aspect that you mention can be implemented using an OAuth2 style redirect_uri.
I think that should answer your concerns. But feel free to expand.
-
Ahh… that would be much better. The main point of the iframe is how it opens up sharing. A shop is no longer a destination, but like YouTube, can be shared and embedded anywhere. It would be a nightmare if the embed code included personal information or what price a product should be set at.
OAuth might solve that. But wouldn’t people have to authorize each individual Merchant?
-
The simplest way of using this is what we call the TransferRequest which doesn’t use OAuth. It just performs the payment. But we do reuse some of the OAuth 2 parameter names such as redirect_uri. TransferRequests can easily be embedded by non technical people in their blogs, Facebook pages etc.
OAuth 2 is used in what we call the TransferAuthorization which is the slightly more advanced way of using OpenTransact, that most sophisticated merchants would want to use.
Essentially by hitting the Pay button you are authorizing the merchant to perform the payment using OAuth2 similar to a traditional Credit Card authorization. All they are allowed is the payment you authorized. It is handled transparently though and looks just like a regular payment.
If they require address or email they add an id_token to the OAuth 2 response_type parameter, which magically turns it into an OpenID Connect request at the same time.
-
-
Interesting!
One thing, though. I don’t like the idea that the payment info and personal information is being sent as part of the URL. It would be easy for an attacker to modify it.
One important part of my concept is that the client is never exposed to product, payment, or personal information. And after the transaction, not even the merchant would have the data.
The to field just contains the payment email address for the merchant. You can also register an application and use an OAuth2 style client_id which hides all of that.
None of the personal information is necessarily shared with the merchant, unless they request it.
Product information can be added as a url using the for parameter. While we don’t specify what happens on the other side, we expect an RDF/microdata/OpenGraph kind of product meta data to be developed.
Finally the delivery aspect that you mention can be implemented using an OAuth2 style redirect_uri.
I think that should answer your concerns. But feel free to expand.
Ahh… that would be much better. The main point of the iframe is how it opens up sharing. A shop is no longer a destination, but like YouTube, can be shared and embedded anywhere. It would be a nightmare if the embed code included personal information or what price a product should be set at.
OAuth might solve that. But wouldn’t people have to authorize each individual Merchant?
The simplest way of using this is what we call the TransferRequest which doesn’t use OAuth. It just performs the payment. But we do reuse some of the OAuth 2 parameter names such as redirect_uri. TransferRequests can easily be embedded by non technical people in their blogs, Facebook pages etc.
OAuth 2 is used in what we call the TransferAuthorization which is the slightly more advanced way of using OpenTransact, that most sophisticated merchants would want to use.
Essentially by hitting the Pay button you are authorizing the merchant to perform the payment using OAuth2 similar to a traditional Credit Card authorization. All they are allowed is the payment you authorized. It is handled transparently though and looks just like a regular payment.
If they require address or email they add an id_token to the OAuth 2 response_type parameter, which magically turns it into an OpenID Connect request at the same time.
Very interesting.