OmniScript Multi-Line Payment Processing Engine

Overview

The OmniScript Multi-Line Payment Processing Engine was designed to solve a recurring problem in digital application flows: how to handle multiple payment lines in a clean, reusable, and scalable way without rebuilding payment logic for every form.

Instead of treating payments as a simple single-amount checkout step, I designed the engine to manage structured line items, cart creation, transaction creation, payment gateway orchestration, receipt logic, and post-payment continuity inside an OmniScript-driven experience. This made the payment process more adaptable across multiple council and Salesforce workflows.

The challenge

Many business applications do not have just one fee. They can include multiple charge lines, different receipt types, GST rules, linked records, customer details, and transaction metadata that all need to stay connected through the payment flow.

The challenge was to build one reusable OmniScript payment engine that could be dropped into different application journeys, preserve context, create the required Salesforce records, and redirect the user into the external payment process without losing operational traceability.

What the engine needed to solve

• Support multiple payment lines in a single payment flow
• Preserve structured fee and receipt metadata
• Create shopping cart and transaction records consistently
• Link payments back to the source application record
• Support guest and logged-in user scenarios
• Handle payment redirect and return flow cleanly
• Enable reuse across multiple OmniScript-based services

Engine architecture

I designed the engine as a reusable OmniScript-compatible LWC pattern that works as an orchestration layer between the user, OmniScript data, Salesforce records, and the external payment gateway.

1. OmniScript as the input and orchestration context

The engine receives structured payment data from OmniScript, including payment amounts, references, module information, receipt types, and customer context. This makes it possible to embed the same engine into multiple flows without rewriting the core logic.

2. Cart and transaction creation layer

Once the payment input is validated, the engine creates the cart record and then creates one or more transaction records. Each transaction line carries its own payment metadata so the resulting payment structure remains auditable and meaningful.

3. Linked-record continuity

A critical part of the design was linking the payment flow back to the source application or case record. That ensured the payment process was part of the end-to-end service journey, not an isolated financial event.

4. Gateway redirect and return handling

After record preparation, the engine calls the payment service and redirects the user to the payment gateway. Return URLs, receipt URLs, and customer information are all managed in a way that supports both operational continuity and user experience.

OmniScript input data
        ↓
Validate line items and customer context
        ↓
Create shopping cart
        ↓
Create multiple transactions
        ↓
Link cart to source record
        ↓
Call payment service
        ↓
Redirect to payment gateway
        ↓
Return and continue application journey

This architecture made the payment process reusable, traceable, and much easier to standardise across multiple digital services.

Implementation example

One of the core patterns in the engine was converting OmniScript arrays into structured transaction records before making the payment call. The example below shows the type of orchestration logic used in practice.

const transactions = this.tpaymentAmount.map((amount, index) => {
    return {
        sobjectType: "Transaction__c",
        Shopping_Cart__c: this.cartId,
        Account__c: this.tAccount[index],
        Module_Reference__c: this.tmduRef[index],
        Module_Account__c: this.tmduAcc[index],
        Payment_Amount__c: amount,
        Receipt_Type__c: this.treceipttype[index],
        UID__c: this.tUID[index]
    };
});

createMulitpleTransactionsOnShoppingCart({ newRecord: transactions })
    .then(() => {
        return makePayment({
            cartId: this.cartId,
            returnUrl: this.returnUrl,
            receiptUrl: this.receiptUrl
        });
    })
    .catch(error => {
        console.error(error);
    });

The strength of this pattern is that the same engine can accept structured inputs from different OmniScripts while still generating a consistent payment model underneath.

In practice, the implementation combined OmniScript, LWC, Apex, cart and transaction objects, gateway redirection, and record linking.

Visual examples

This kind of project is best illustrated through flow diagrams showing OmniScript input, cart creation, multi-line transaction generation, payment gateway redirect, and return continuity. Those visuals help communicate that this is an engine, not just a payment button.

Comparison table

Project highlights

Business value

The biggest value of the engine was standardisation. Instead of solving multi-line payments differently for every service, the organisation gained a repeatable pattern that improved consistency, reduced duplication, and made complex payment journeys much easier to support operationally.

• Reduced duplicate payment logic across applications
• Improved consistency in cart and transaction creation
• Supported complex multi-line payment scenarios
• Improved linkage between payments and source records
• Created a scalable foundation for future OmniScript-enabled services

FAQ