Overview of Payments in Fluent
Author:
Matt Salmon
Changed on:
9 Dec 2024
Overview
- Fluent Order Management enables the management of payments throughout the lifecycle of an Order.
- Build custom payment logic into the Order workflow using the OMX Workflow Framework and provided entities.
- This document provides an overview of the Payment Data Model and GraphQL API capabilities and does not include any reference Rules, Workflows, or UX Components.
Key points
- Pre-requistes
- Data Model
- Entities
- Explanation of the Entity Relationships through an Example
- Relationship details
- GraphQL queries required for Payments
Pre-requisites
You must have knowledge of how the Workflow Framework works.
Data Model
The following data model is the global data model which shows where the Payments solution sits in the Fluent platform.

The following data model outlines the entities available to manage payments.

Entities
These are the entities involved in the Payment domain.
Entity | Description |
| Represents the sales for a customer |
| A pool of funds available in to pay for an |
| A plan to move items in to deliver on a promise made to a customer |
| Represents the of capturing or refunding part or all of a financial transaction |
| A log of activities that have occurred whilst processing a payment through its lifecycle |
| The source of record for a group of financial operations relating to a customer |
| The document representing the itemised charge to a customer for the supply of goods |
| A memorandum issued to indicate a change in an orders sale price |
Explanation of the Entity Relationships through an Example
The following use case explains the relationship between different entities in the Payments domain.
High-level example
This example serves as a practical walkthrough of how the entities related to payments are intended to be used to capture funds throughout the lifecycle of an .
- A customer ordered 3 items from an electronic store. The items are a Laptop for $1500, a TV for $1000 and a Speaker for $500. A total of $3000.
- The order was paid for with 2 transactions. $500 via gift voucher and the remaining $2500 with a credit card.
- The order was then split and fulfilled at 2 separate locations which means 2 shipments were sent to the customer's delivery address.

Entity relationships for the above example
- When an
`Order`
is created using the`createOrder`
query, 2`FinancialTransactions`
are created with the status`CREATED`
. 1 with the`paymentMethod`
"CREDITCARD" and another with "GIFTVOUCHER". - Given the order needs to be split, two
`Fulfilments`
should then be created by the`createFulfilment`
query. - Fulfillments are processed which includes picking and packing of fulfillment items.
- Payments are captured once corresponding fulfillments are shipped.
`Fulfilment 1`
contains a TV that is $1000 and is paid through a CREDITCARD (Payment 1) using the`createPayment`
query.- The status of the
`FinancialTransaction`
with the`paymentMethod`
CREDITCARD changes to`PARTIALLY_CAPTURED`
by`updateFinacialTransaction`
query to reflect the fact the remaining funds have not been captured yet.
- The status of the
`Fulfilment 2`
contains a Laptop and a Speaker for $2000 and is partially paid with the remaining authorised funds on the`FinancialTransaction`
with`paymentMethod`
CREDITCARD (Payment 2) and the remaining outstanding amount via the other`FinancialTransaction`
where the`paymentMethod`
is GIFTVOUCHER (Payment 3) using`createPayment`
query.- The status of both FinancialTransaction becomes
`CAPTURED`
at this point using the updateFinancialTransaction query.
- The status of both FinancialTransaction becomes
- Multiple
`PaymentTransactions`
will be created for each`payment`
using the`createPaymentTransaction`
query containing the`status`
log for each payment. For example, credit card`PENDING`
, or credit card`CAPTURED`
. - Once all the payments are captured, 1 invoice is generated using the
`createInvoice`
query for each`fulfilment`
and is sent to the customer.
Relationship details
relationships related to payments are documented below.
Name | Relationship Type | Comment |
Customer_Order | Zero-Many | A customer can place many orders at different times, so one |
Customer_BillingAccount | Zero-Many | A customer can create many accounts each having its own details so, one |
Order_Fulfilment | Zero-Many | An can be split into many fulfillments due to different fulfilments being fulfilled from different locations or at different times, so 1 |
Order_BillingAddress | Zero-One | A customer can optionally add a billing address while ordering items from a store, so an |
Order_Invoice | Zero-Many | An can have many invoices through the relationship of a . An can have multiple fulfillments and each will have an invoice, so one |
BillingAccount_BillingAddress | Zero-One | A customer can have one address per so, a |
FinancialTransaction_Payment | Zero-Many | A financial transaction can have multiple payment methods such as a Credit Card and a Gift Card, so a |
Fulfilment_Payment | Zero-Many | A customer can pay for through multiple payment methods such as a gift card and a credit card, so a |
Payment_PaymentTransaction | One-Many | A payment will go through different stages such as authorised, captured, failure etc. Each stage is recorded as a payment transaction so, 1 |
Order_ReturnOrder | Zero-Many | A customer may want to return different items of at different times hence creating multiple return orders for each item, so 1 |
ReturnOrder_CreditMemo | One-One | When an is returned, or exchange happens, a is generated for the return , so 1 |
BillingAcount_CreditMemo | Zero-Many | There can be multiple transactions, adjustments or refunds involved with a customer’s billing . Each transaction or adjustment generates a new so, 1 |
CreditMemo_Payment | Zero-Many | If the initial payment was made by a credit card and PayPal by a customer, the respective amount will be paid back to each of the payment methods so, one |
GraphQL queries required for Payments
The following queries are required to build a Payment solution:
Query | Description |
| Creates a new |
| Creates a new |
| Creates a new |
| Creates a new |
| Creates a |
| Creates a |
| Updates the status of the |
| Creates a new |
| Updates a |
| Creates a |
| Creates a new |
| Creates a new |
| Creates a new |
You can find all the queries related to Payments here(deprecated).