Contrairement à ce que son nom laisse penser, cette solution, conçue par un suisse, n'est pas un service de paiement à proprement parler. Son seul objectif est de simplifier l'acte de paiement, en exploitant les connexions aux réseaux sociaux des internautes.
Le principe est le suivant : pour commencer, vous associez votre compte PayPal ou Google Checkout à votre compte Facebook, Twitter, Google ou autre... Si vous êtes comme la plupart des internautes adeptes des réseaux sociaux, vous restez identifié en permanence sur ces sites. Dès lors, au moment de régler un achat, un simple clic sur le bouton de paiement va vous authentifier auprès du réseau social choisi et valider le paiement, sans aucune autre intervention de votre part. Impossible en effet de faire plus simple !
Il s'agit donc, finalement, d'une solution de délégation d'identification et d'authentification appliquée aux paiements. Malheureusement, la simplification apportée se fait au détriment de la sécurité (il faut également noter que les deux services de paiement supportés ont déjà des systèmes d'identification simples). En effet, l'accès à un navigateur sur lequel un utilisateur a ouvert une session suffit pour réaliser des achats... Malgré tout, comme je le suggérais en introduction, l'idée de base est intéressante et pourrait être mûrie pour imaginer une solution plus "réaliste" (à moins que ce ne soit qu'une illusion...).
Falk Wolsky, concepteur de SociallyPay a souhaité apporter une réponse, que je relaie ici (car il n'a pas pu enregistrer lui-même son commentaire) :
RépondreSupprimerEverything is correct with what you write - but on the important topic of "security" I have something to say.
I think, SociallyPay makes web Payments more secure. Why?
Normally users have to enter sensitive data for payments online. Or users have a PayPal or other similar account and have to login on it.
SociallyPay uses the authentication services from social networks like Facebook. And these providers use technologies like OAuth. If users pay with the SociallyPay-Button we don't know, get or transmit login credentials. Neither SocialMedia Logins or Payment Provider Logins.
We also don't know, store or process credit card or a bank account information. We don't have this info at any time ;-)
The Button itself (the HTML representation) stores only hashed keys and no other information. Our back-end then gets the necessary information via the Auth-Mechanism and proceed to transfer the information to the payment provider via an secured network.
That means that, in principle, one can manipulate the button" - but our back-end blocks it then.
That is "the inner level".
At the "outer level" is a "user-controlled fraud mitigation system".
SociallyPay makes simple a time- and value-based agreement with users. For example the user configures (on one simple form on sociallypay.com) that he authorizes, e.g., SociallyPay to transfer a maximum of $200 for 3 months, and a maximum of $20 a day.
Trough this SociallyPay can impersonate "the user" against the payment provider. The user then have to login and confirm this agreement onece with his provider and can pay with the SociallyPay button for 3 months.
It will be impossible for SociallyPay to make payments outer these limits!
I think - as I say - this is more secure than some payment methods actually working.
Hope this clarify some things.