Payment-System Architecture
Developing the “Big Picture”
Finding good hardware and building a wiring circuit was a major part of our coffeemaker project. Another important part is the software architecture. Let’s try to find a solution.
Instead of maintaining a tally and manually counting dashes, we decided to support several payment methods. One is based on Amazons AWS, especially DynamoDB and Lambda, and some cool other services like IFTTT and Google Docs. This is the “big picture”.
We use DynamoDB to save a record whenever a customer pulls himself a cup of coffee. The payment system uses parts from the AWS-SDK to push a MQTT-message to the AWS IoT Core platform. In AWS IoT Core we use a rule to extract and save the payload of the message in a DynamoDB table. The payload is a JSON object containing the following information.
| Attribute | Description |
|---|---|
| cardId | The RFID / NFC-tag unique ID |
| product | The number of the chosen product |
| price | The price for the product |
| paymentMethod | The payment method |
Although DynamoDB is a great data sink, it’s not the best choice for analyzing data and billing. Fortunately DynamoDB supports event sourcing, this feature is called streams. Streams are able to send events in case of adding, deleting or changing data. We could use a Lambda-function to receive these events and send them to another service which better suits our needs.
We’re going to build a Lambda-function which will send the data to a Google Doc sheet. We don’t use the Google-API, instead we’re going to create a IFTTT applet based on the Webhook-action. All our Lambda-Function has to do is firing a HTTPS/REST call when a new DynamoDB event arrives.
At the moment we still have to chase money but the decisive change is, now it doesn’t take much effort to prepare the bill. Just glance at the Spreadsheet and press a button and everybody gets delivered a eMail with his personal bill.