Fingermark Cringer

Payment SDK

Fingermark Payment SDK Architecture

Overview

Fingermark Payment SDKs have been designed to handle 3rd party consumption, as well as Supersonic integration.

This is achieved through using a ports and adapters or hexagonal architecture pattern where payment integrations (@fingermarkglobal/adyen) expose ports to be used, while @fingermarkglobal/transactions acts as the adapter to bring them into the Supersonic ecosystem.

Ports (Payment Integration)

A payment integration must expose the following interface.

const { pay, refund, settle } = new PaymentIntegration();

  • pay

    The main payment function. This will receive payment information such as amount

  • refund

    The main refund function. This will receive refund information such as transactionId

  • settle

    The "settlement" or "confirmation" function. This will confirm payment/s has completed to the pinpad or integration service.

Each of these functions must return a running XState machine with the current state of the operation. The machine must contain the following states:

  • loading
  • failure
  • success

This is to ensure payment processes work across all client UIs.

Adapter (Payment SDK)

The @fingermarkglobal/transactions SDK exposes a buildPaymentHandlers function that exposes the ports pay, refund and settle requests. This is so the Payment SDK can link the provider integration into the Supersonic ecosystem

  • KAS settings intergration
  • UI payment polymorphism (UI's can switch payment providers without any code changes)
  • Metadata capturing (Attatching Supersonic logging events to machines)

Diagram

Payment Architecture Diagram

Additional Resources

Outstanding

  • Migrate to typescript for easier enforcment and self documentation of interfaces
  • Add more ports for other dependencies (database calls, settings providers etc)