X

Engineer Makes Square Transactions Possible On Google Home

Square engineer Pierre-Yves Ricau has now created a completely new way to complete business transactions using only voice input. Citing inspiration from jobs that require complex, hands-on work – in particular, the work of a barista – he decided now was the time to create a system that doesn’t require users to press any buttons or tap on a screen. His creation uses nothing more than public API, a Google Home device, a Square reader, the popular “If This Then That” (IFTTT) application, and of course a “customer” device. Ricau specifically uses Apple Pay in his example to show how the system works across platforms, but it seems as though it could easily be adjusted to suit users across all platforms and be used with either the NFC or card reader offered by Square.

As Ricau explains at the source, the premise of the problem seems as though it would be easy enough to solve. However, the reality of creating a program to solve that problem is generally more complex than the simplicity of the problem would appear to imply – especially when considering the key differences between the devices and platforms used. First, the “merchant” needs to instantiate the program by asking Google to charge the appropriate amount for the service or product. This is done with pre-determined phrasing so that other components of the system can pick out key variables from the other words. Then, Google Home contacts IFTTT, which in turn gets and sets the amounts and associated purchase notes as required. Those values are sent to the Square servers, setting the transaction there, before sending data back allowing the reader – in this case, an NFC reader – to activate. The perspective customer taps his or her device to send the appropriate data back to the servers so that the transaction can be processed. Finally, the money shuffles around between Square servers and the associated bank accounts before the customer finally receives what they’ve paid for. All of that complexity may seem to be a bit much, but the idea and the resulting code really highlights how more legacy-based means of bridging the gap between differing standards can be used in new and meaningful ways. Moreover, it shows that such feats can be accomplished with publicly available API and hardware.

Truthfully, it doesn’t happen very often that a new technology or device is released and not followed up almost immediately by the development of some previously unrecognized potential. In this case, whether or not Ricau’s solution gains any kind of traction may be limited by several factors, such as the reliability of picking up a worker’s voice amidst the bustle inside a busy coffee house. In the end, this may just be one of those experiments that could work but isn’t ever used, even if it does get everybody thinking.