Skip to content

Aston Payment Gateways

Planned feature / work in progress

Aston's payment gateway service will by default process payments and tokenise cards using Braintree, however it has been architected to support additional / custom payment gateways.


Order and Payment Components


Card tokenisation flow:

Card tokenisation

Payment flows:

In store payments

Order ahead payments

Custom Gateways

In addition to Braintree it is possible to integrate additional gateways by implementing an adapter in the Payments service.


  • Card tokenisation for mobile wallet - since Aston is focused on processing payments at the point-of-sale
  • Pre-authorising payments - this is required for bar tabs, order ahead. It may be possible to substitute this functionality with refunds
  • Cancelling and refunding payments
  • Customer profiles, and digital wallets - however their absense can be substituted by creating a persistence layer within the adapter which will increase the time and effor required to integrate the gateway.
  • Retrieval of past payment details - however their absense can be substituted by creating a persistence layer within the adapter which will increase the time and effor required to integrate the gateway.
  • Drop-in UI / card management UI - at present we will only consider gateways that provide their own UI such as Braintree's drop in UI. This is not a technical limitation, but a business decision to limit PCI scope and may be reconsidered in the future. The results (typically a nonce) of the drop-in UI are then sent to createPaymentMethod to exchange for a long lived token.

Adapter Interface

Each gateway must implement an adapter meeting the following interface:

  * Defines an adapter for an external payments provider
interface IPaymentAdapter {
  createCustomer(customer: ICustomer) : Promise<ICustomer>
  getCustomer(customerId: string) : Promise<ICustomer>
  deleteCustomer(customerId: string) : Promise<void>

  createPaymentMethod(customerId: string, gatewayArgs: any, options?: { validate: boolean, failOnDuplicate: boolean }) : Promise<IPaymentMethod>
  listPaymentMethods(customerId: string) : Promise<IPaymentMethod[]>
  deletePaymentMethod(customerId: string, token: string) : Promise<void>

  chargePayment(paymentMethodToken: string, paymentRequest: IPaymentDetails) : Promise<IPaymentResult>
  authorizePayment(paymentMethodToken: string, paymentRequest: IPaymentDetails) : Promise<IPaymentResult>
  submitPayment(paymentId: string) : Promise<IPaymentResult>
  cancelPayment(paymentId: string) : Promise<IPaymentResult>

  get(paymentId: string) : Promise<IPaymentResult>

  verify() : Promise<boolean>


The banking service handles batching of orders on a daily basis. Each individual merchant can have a different close-of-business time that acts as a cutoff time for a day's business.

Batches of transactions grouped per-merchant-per-gateway-per-day, and then again into a combined per-gateway-per-day batch.

The banking service the emits batch events when complete that can be used by the reporting service to generate ABA files, summaries, and tax invoices.


The reporting service compiles batch and other information into human and machine readable formats, such as PDFs and ABA files.

The supported reports are:

  • Daily merchant transaction summaries.
  • Daily merchant tax invoices (where fees are collected)
  • Daily ABA files for Australian gatways (where configured)


See the admin UI