CAN Albert Quick setup guide

Version 6.0
September 2016
Albert
POS Integration Guide.

2 |Commonwealth Bank Albert POS Integration Guide
1. Document Purpose 3
2. Introduction to Albert 3
3. Outline of an Integration 4
4. Key Considerations for Albert 4
5. Common Pairing Scenarios 5
5.1 Direct Connection to POS 5
5.2 Direct Connection with Registry Service 7
5.3 Web Based Middleware 9
5.4 Web Based POS 12
6. Points to Consider 14
6.1 Security 14
6.2 Other things to keep in mind 14
7. Passing the Transaction 15
8. Test and Submit on App bank 16
8.1 Testing 16
8.2 App Submission 16
9. Billing 16
10. App Support 17
Contents

3 |Commonwealth Bank Albert POS Integration Guide
This document outlines the main considerations and methods used for Albert POS integration. Key integration
methods, considerations and concerns are reviewed, along with a code example and how to handle
intent results. For further support, refer to documentation and Forums on piappbank.com.au or email
SmartTerminals&[e-mail].
Albert is an Android based EFTPOS tablet that allows merchants to securely take a payment, print a receipt, and
offer their customers an interactive touch screen experience, on a single device. Albert has the capability to run
Android based apps, managed via a secure portal – App bank.
Key device specifications:
7” touchscreen
Integrated thermal printer
Camera
Magnetic Swipe, Chip EMV, and NFC reader for card payment
Albert has been developed in conjunction with Aevi.
1. Document Purpose
2. Introduction to Albert

4 |Commonwealth Bank Albert POS Integration Guide
Albert is SEAndroid Enforcing.
Albert is currently running Android 4.0.4.
The Merchant Menu Library is required for apps to run on Albert.
Firewall restrictions are in place that limit inbound network connectivity.
There are no back, home, and recents buttons seen by the end user.
The NDK is not supported. C and C++ is not allowed.
For hybrid apps, contact us at smartterminals&[e-mail]
4. Key Considerations for Albert
Building your own integration allows you to use your own POS system to control the merchant interaction. The
Albert can then act as a customer interaction tool as well as a payment device.
Albert POS Integration
The Albert POS application (POS Client), residing on Albert, must establish a connection to the relevant POS
register (POS Terminal).
The POS register needs to be able to send and receive variables from the POS Client. The POS Client receives the
variables, and creates an intent to the CommBank Standard Payment app on Albert.
The CommBank Standard Payment app completes the entire transaction where the app takes the customer’s card
details to process the transaction, prints the merchant and customer receipts and sends the transaction results
back to the POS Client.
The POS Client then transmits the details back to the POS.
3. Outline of an Integration

5 |Commonwealth Bank Albert POS Integration Guide
5.1 Direct Connection to POS
There are four possible pairing scenarios between a POS and Albert.
Direct Connection to POS is the recommended approach. The other three options are technically feasible but carry
dependencies on variable factors that may be unique to each case and environment.
The easiest way to integrate a POS with Standard Albert running the Standard Payment app.
Once the connection between the POS app and POS Client is open, it can serve multiple requests, in series,
untilclosed.
5. Common Pairing Scenarios
Components
Component Description
POS app The POS app resides on a separate machine and can run any technology stack such as
Windows or Linux. Connectivity is assumed to be via WiFi. Connecting via 3G would be
harder as the POS would have to allow connections from the internet.
POS Client The POS Client is an app or service that runs on Albert that may or may not have an
interface. This is responsible for sending and receiving requests to and from the POS. It
uses the Albert SDK by Wincor to launch the CommBank Standard Payment app. This
client would also have to maintain a long running connection/socket/web socket with the
POS to allow two way communication (e.g. socket.io). As Albert doesn't allow incoming
connections, this connection needs to remain in place and needs to be initiated by Albert.
CommBank
Standard
Payment app
A black box that handles all the payment processing. It is launched using the SDK and
returns a response to the calling app.
POS app POS Client
CommBank
Standard
Payment app
POS Terminal
1. Connect
2. Payment Request
5. Payment Response
4. Payment Response 3. Payment Request
Albert Terminal
POS owned and developed
CommBank owned and developed
KEY

6 |Commonwealth Bank Albert POS Integration Guide
Sequences
ID Sequence Description
1Connect Establishes a connection with the POS (it is assumed this is over manually
defined IP). Albert establishes an outgoing long lived connection such as
asocket.
This is due to Albert being unable to accept incoming connection requests
because of firewall restrictions.
2Payment Request The POS sends a message to the POS client over the established
connection. The format of this message is left to the POS vendor to decide.
It can be extended to support any command recognised by the POS Client
such as "display advert", "display menu" etc.
3Payment Request The POS Client uses the SDK to make a payment request to the
CommBank Payment app.
4Payment Response Once the payment finishes, a response is sent back to the POS Client.
5Payment Response The POS Client sends a message back to the POS over the
established connection. The format of this message is left to the POS
vendor’sdiscretion.
Pros
Ease and simplicity of implementation
Cons
Connection to POS app defined via static IP by default – if a change is required, IP is manually set on Albert
POS Client.
Addressed in Registry Service example below.
Implementation Considerations
Securing the connection to the POS.
Securing traffic between the POS and POS Client.
Network outages and connection retries.
Payment app failures e.g. DECLINE returned.
Timeouts from a payment taking too long.
A failure causing the POS to never receive a Payment Response.

7 |Commonwealth Bank Albert POS Integration Guide
5.2 Direct Connection with Registry Service
This gives the connection establishment responsibility to a service, allowing for external management of terminal
and POS assignment. A web interface could be developed to manage the "Connection Service" to monitor, audit or
control the allocation of terminals to POS systems.
Direct connection using a registry service is more suitable to scenarios where there are multiple locations and
multiple terminals that need to be managed off-site at a central location/head office.
POS Client queries SDK for Merchant and Terminal ID.
POS Client connects to a registry service, identifies itself, and receives IP address of the POS it should pairwith.
POS Client establishes long lived connection with POS, and proceeds as above.
POS app
Registry and
Lookup
POS Client
CommBank
Standard
Payment app
POS Terminal
4. Connect
2. Request an Albert 1. Register Albert
3. Connect to POS Request
5. Payment Request
8. Payment Response
7. Payment Response 6. Payment Request
Albert Terminal
POS owned and developed
CommBank owned and developed
KEY

8 |Commonwealth Bank Albert POS Integration Guide
Components
Component Description
POS app The POS app resides on a separate machine and can run any technology stack such as
Windows or Linux. Connectivity is assumed to be via WiFi. Connecting via 3G would be
harder as the POS would have to allow connections from the internet.
POS Client The POS Client is an app or service that runs on Albert that may or may not have an
interface. This is responsible for sending and receiving requests to and from the POS. It's
also responsible for registering itself as an available Payment Terminal with the "Registry
and Lookup Service". It uses the Albert SDK by Wincor to launch the CommBank Standard
Payment app. This client would also have to maintain a long running connection/socket/
web socket with the POS to allow two-way communication (e.g. socket.io). As Albert
doesn't allow incoming connections this connection needs to remain in place and needs to
be initiated by Albert.
CommBank
Standard
Payment app
A black box that handles all the payment processing. It is launched using the SDK and
returns a response to the calling app.
Registry and
Lookup
Provides a service for Alberts to register themselves as an available Payment Terminal
as well as a way for a POS to request an Albert. This would allow management of
multiple terminals and POS systems via a central point. This would lend itself to a simple
webservice.
Sequences
ID Sequence Description
1Register Albert Registers itself as available with (for example): IP address, location, terminal
ID, features available.
2Request an Albert The POS requests an Albert that may be based on: Location, terminal ID,
store, features etc.
3Connect to POS
Request
The service tells Albert it’s been selected to be a Payment Terminal for a
POS. It's given the POS's IP address and is told to connect to it.
4Connect POS Client opens up a long running connection with the POS to allow two-
way communication.
5Payment Request The POS sends a message to the POS Client over the established
connection. The format of this message is left to the POS vendor to decide.
It can be extended to support any command recognised by the POS client
such as "display advert", "display menu" etc.
6Payment Request The POS Client uses the SDK to make a payment request to the
CommBank Payment app.
7Payment Response Once the payment finishes, a response is sent back to the POS Client.
8Payment Response The POS Client sends a message back to the POS over the
established connection. The format of this message is left to the POS
vendor’sdiscretion.

9 |Commonwealth Bank Albert POS Integration Guide
Pros
Allocation of terminal to POS is centrally controlled.
Cons
Requires a web based Connection Service which is more development and support effort.
The communication between POS and Albert is direct 1-to-1 and doesn't go via a message broker. This is fine
but offers less monitoring or control.
Implementation Considerations
The Connection Service becoming a single point of failure.
Securing the connection to the POS.
Securing traffic between the POS and POS Client.
Network outages and connection retries.
Payment app failures e.g. DECLINE returned.
Timeouts from a payment taking too long.
A failure causing the POS to never receive a Payment Response.
5.3 Web Based Middleware
Similar to the direct connection with registry service approach but taken a step further by completely decoupling
Albert and the POS. Albert and the POS are not dependant on each other, increasing solution robustness as they
don't have to know of the other entities' existence.
Beneficial if there are multiple subscribers that can use event information to trigger other actions, log data, provide
analytics etc.
It assumes a piece of Message Oriented Middleware (MOM) that provides the message orchestration via queues,
publish/subscribe, topics etc.
POS connects to a middleware service that will handle all transaction communications.
Albert app queries SDK for Merchant ID and Terminal ID, and connects to middleware service.
Middleware service passes all communications between POS and Albert.
Middleware could be set up as a publish/subscribe queue, or a direct message transfer.

10 |Commonwealth Bank Albert POS Integration Guide
Components
Component Description
POS app The POS app resides on a separate machine and can run any technology stack such as
Windows or Linux. Connectivity is assumed to be via WiFi. Connecting via 3G would be
harder as the POS would have to allow connections from the internet.
POS Client The POS Client is an app or service that runs on Albert that may or may not have an
interface. This is responsible for sending and receiving requests to and from the Publish/
Subscribe Queue. It's also responsible for registering itself as an available Payment Terminal
with the Publish/Subscribe Queue as well as two-way messaging. It uses the Albert SDK
by Wincor to launch the CommBank Standard Payment app. This client would also have
to maintain a long running connection/socket/web socket with the Publish/Subscribe
Queue to allow two-way communication (e.g. socket.io). As Albert doesn't allow incoming
connections this connection needs to remain in place and needs to be initiated by Albert.
CommBank
Standard
Payment app
A black box that handles all the payment processing. It is launched using the SDK and
returns a response to the calling app.
Publish/Subscribe
Queue
Provides a way for an Albert to register itself as a payment terminal and a POS to request
a payment terminal. It also acts as a message broker between the POS and Albert. It's
ideally suited to handling multiple POS and multiple Alberts and possibly across multiple
merchants. It will also need to provide management of open sockets to Albert and to the
POS as well as web services to register the devices. This box could well be broken down
further into sub components such as socket server and web service.
POS app
Publish Subscribe
Queue
POS Client
CommBank
Standard
Payment app
POS Terminal
2. Request an Albert
3. Albert Assigned
4. Payment Request 5. Payment Request
9. Payment Response
MOM
8. Payment Response
1. Register Albert
7. Payment Response 6. Payment Request
Albert Terminal
POS owned and developed
CommBank owned and developed
KEY