Architecture Overview

unaric payments architecture is built around a modular data model that separates different aspects of the payment lifecycle at its core, four key objects form the backbone of the system objects docid\ f33l 1zecsfrnsvxhueo5 object name unaric payments authorisation api name asp04 authorisation c this object records the approval details for a payment before funds are captured, an authorisation is generated to confirm that payment methods are valid and that sufficient funds exist an authorisation record is linked to both one off and recurring transactions, serving as a reusable reference for subsequent payments docid\ nf5zal0y9xdg fyhctw8c object name unaric payment api name asp04 payment c the payment object represents the actual financial transaction it captures details such as the transaction amount, payment method, status, and related metadata every payment is typically associated with an authorisation that validates the transaction in addition, the payment object forms the basis for any follow on actions, such as refunds docid\ lg6oxx86 ru4kvicq tq object name unaric payments refund api name asp04 refund c when a transaction needs to be reversed, the refund object is used it maintains all the details about the reversal process, including the refunded amount and the status of the refund operation refund records reference the original payment to ensure complete traceability and auditability docid\ mr7d24nqdmzsfhovef2wd object name unaric payment schedule api name asp04 paymentschedule c the system is designed with clear relationships between these objects an authorisation record acts as the anchor it is referenced by both payment and schedule objects for one off transactions, the payment record is directly tied to its corresponding authorisation in recurring payment scenarios, the schedule object uses an existing authorisation to generate a series of payment records automatically if a refund becomes necessary, the refund object connects back to the original payment record, creating a full, auditable trail across the payment lifecycle objects flowchart graph td; unaricpayments\["\<b>unaric payments\</b>\<br/>authorisations\<br/>payments"] < >|webhooks| aws\["\<b>aws\</b>\<br/>translation layer\<br/>webhook processing"]; paymentpage\["\<b>payment page\</b>\<br/>payment details\<br/>bank details (authorisation)"] > aws; aws < >|api| unaricpaymentssf\["\<b>unaric payments / sf\</b>"]; paymentpage < > unaricpaymentssf; subgraph unaricpaymentssf\["\<b>unaric payments / sf\</b>"] authorisations\["\<b>authorisations\</b>\<br/>customer bank details/tokens\<br/>mandate references\<br/>accounts/contacts"]; paymentschedule\["\<b>payment schedule\</b>\<br/>authorisation\<br/>amount\<br/>frequency"]; payments\["\<b>payments\</b>\<br/>accounts, contacts\<br/>payment outcome\<br/>authorisation"]; refund\["\<b>refund\</b>\<br/>payment\<br/>amount"]; end unaricpaymentssf > authorisations; unaricpaymentssf > paymentschedule; unaricpaymentssf > payments; unaricpaymentssf > refund; %% apply styling classdef startend fill #002d4c,stroke\ none,color #fff,font weight 400,font family\ helvetica,rx 5px,ry 5px; classdef process fill #42a4dd,stroke\ none,color #fff,font weight 400,font family\ helvetica,rx 5px,ry 5px; classdef decision fill #f4f7fa,stroke\ none,color #002d4c,font weight 400,font family\ helvetica,rx 5px,ry 5px; class unaricpayments,aws,unaricpaymentssf startend; class paymentpage,payments process; class authorisations,paymentschedule,refund decision;