make IT better

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.

comments powered by Disqus
RSS Feed