Payment Integration — What Your Business Actually Needs to Know

Payment integration is one of the areas where both BC and LS Central clients have the most questions and the least clear information. Here is a practical breakdown of what payment integration means, what the options are, and what to think about when choosing.

Payment Integration in LS Central (POS Payments)

LS Central has its own payment framework — LS Pay — which provides a standardised interface between the POS and payment terminals (PIN pads, contactless readers, QR code scanners). LS Pay supports chip-and-pin, contactless, mobile wallets (Apple Pay, Google Pay, Samsung Pay), and QR code payments, depending on which payment service provider you connect it to.

LS Pay connects to the payment terminal through a payment service provider (PSP) middleware layer. Common PSPs in the GCC and South Asia include network-provided acquirers (KNET in Kuwait, Benefit in Bahrain, network banks in Saudi Arabia), global processors (Adyen, Stripe), and regional processors. The key thing to understand: LS Pay is the connector; the PSP is the contract. You choose your PSP based on the rates, currencies, and settlement timelines that work for your business — LS Pay handles the technical integration.

Split Payments and Mixed Tenders

LS Central handles split payments natively — a customer can pay part of a transaction in cash and part by card, or use loyalty points for a portion and card for the rest. Each tender type posts to a separate tender account in BC's financial module, and the reconciliation is automatic at end-of-day statement time. This sounds simple, but it is an area where many custom-built POS integrations fail: the split tender calculation is correct at the POS but the posting to the financial ledger does not match, creating reconciliation gaps that compound over time.

Payment Integration in Business Central (B2B and AR)

For Business Central clients managing B2B invoicing, payment integration means something different: automating the matching of incoming bank payments to outstanding customer invoices, and managing payment runs to vendors.

Bank reconciliation and payment matching

BC's bank reconciliation module imports bank statements via bank feed connectors or file import (MT940, CAMT.054, CSV depending on your bank). The system then attempts to match each statement line to open customer or vendor ledger entries. With a well-configured matching rule set, 70–85% of payments match automatically. The finance team reviews unmatched items — typically complex payments, short payments, or payments covering multiple invoices.

Electronic payment runs (vendor payments)

BC generates payment files in the format required by your bank (SEPA, ACH, SWIFT MT101, or bank-specific formats). The payment run is built from open vendor ledger entries, filtered by due date and payment terms, reviewed and approved in BC's approval workflow, and exported as a payment file for bank upload. This replaces manual bank transfers and reduces the risk of payment errors.

Payment gateways for online sales

For businesses with an e-commerce channel connected to BC, payment gateway integration — Stripe, PayTabs, Checkout.com, or regional equivalents — captures payment at checkout and creates a confirmed sales order and payment record in BC automatically. The integration handles payment confirmation, failure retry, and refund posting. When built correctly, the e-commerce finance team has zero manual entries for online orders.

ZATCA and Payments — The Intersection

In Saudi Arabia, payment integration has an additional dimension: ZATCA's e-invoicing requirements apply to the invoice that accompanies a B2B payment, not the payment itself. But the two are connected — your payment terms, your invoice timing, and your clearance process all need to be aligned. A payment received before a ZATCA-cleared invoice is generated creates a compliance sequencing issue. We see this most often in businesses that have automated payment capture (via gateway or bank feed) but manual ZATCA submission — the gap between the two creates reconciliation problems and potential compliance exposure.

Choosing the Right Payment Setup

The right payment setup depends on three things: where your customers pay (in-store, online, bank transfer), how many currencies you transact in, and what your bank's file format capabilities are. A supermarket group needs LS Pay with a regional acquirer and multi-tender POS support. A distribution company needs automated bank reconciliation and electronic payment runs. An e-commerce business needs a gateway integration and automatic order-to-payment posting. Most mid-sized businesses need a combination. We map the payment flow before recommending any technical solution, because the technology choice follows from the business model — not the other way around.