---
title: Architecture Overview
slug: payments/architecture-overview
description: Understand the full architecture of Unaric Payments and how it securely processes transactions inside your Salesforce org.
image: https://cdn.images.archbee.com/10Nod6Ww95R3dPr0k0TCJ/u2F0jHj5OTep9goG43P3b_unaric-payments.png
createdAt: 2026-01-13T00:53:22.924Z
---

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

- [Authorisations](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. 
- [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.
- [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.
- [Payment Schedules](docId\:mr7D24NQdmZSfhovEf2WD)
  - **Object Name: **Unaric Payment Schedule
  - **API Name: ** asp04\_PaymentSchedule\_\_c
  - 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

```mermaid
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;

```