Integrations

We work with SAP S/4HANA and SAP Business One, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365 Finance and Supply Chain Management, Dynamics 365 Business Central, Odoo, Sage Intacct and Sage X3, as well as custom and older systems. For each we use the interfaces the vendor supports, so upgrades do not break the integration. Naming a product does not mean a partnership with its vendor.

Read more: ERP integrationLink to this question

Not always. A few stable flows between two systems can be direct API calls. Once several systems exchange data, or you need mapping, queues and monitoring in one place, middleware such as MuleSoft, Boomi or Azure Logic Apps usually pays for itself. If you already own one, we build on it. We set out the trade-offs, including licence costs, before you decide.

Read more: ERP integrationLink to this question

We work with the ISO 20022 messages banks use for corporate payments and reporting: pain.001 for payments, pain.002 for status, and camt.052, camt.053 and camt.054 for account reports. We also handle the SWIFT MT940 and MT942 statements many banks still send. For transport we use host-to-host SFTP, EBICS where banks offer it, and bank APIs. Each bank has its own variant of each format, so we build from the bank’s implementation guide, not from the standard alone.

Read more: Bank integrationLink to this question

We connect banks to SAP S/4HANA, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Odoo and Sage, and to treasury and custom systems. Some ERPs have their own bank communication modules. Where they do, we configure and extend them rather than build around them. Naming a product here does not mean a partnership with its vendor.

Read more: Bank integrationLink to this question

Yes, where the acquirer or processor offers it. ISO 8583 is a framework rather than one format: each acquirer publishes its own specification of fields, message types and network management. We build from that specification, handle authorisations, reversals and advice messages, and test every response code. Where a gateway offers a modern API in front of the acquirer, we often recommend that instead.

Read more: Payments and POS integrationLink to this question

We integrate EMV chip and contactless terminals through the protocol their provider supplies, usually a local or cloud API between the POS and the terminal. The terminal and its payment application are certified by the provider, so we integrate with them rather than change them. We confirm the exact models and protocols with you and the provider at the start.

Read more: Payments and POS integrationLink to this question

It depends on how many connections you have and who will run them. An integration platform such as MuleSoft, Boomi or Azure Logic Apps gives you ready connectors, mapping and monitoring in one place, at a licence cost. Custom services give you full control and no licence, but you maintain more code. We compare both for your case and build on a platform you already own.

Read more: Third-party and API integrationLink to this question

We read each partner’s published limits and design around them: batching requests where the API allows it, caching data that rarely changes, spreading scheduled jobs and backing off when the partner signals that a limit is near. Monitoring shows how close each flow runs to its limit, so growth does not turn into failures.

Read more: Third-party and API integrationLink to this question

The bank usually decides. Host-to-host SFTP is the most widely offered channel for corporate payment files. EBICS is common with banks in Germany, France and neighbouring countries. Bank APIs suit real-time balances and instant payments where the bank offers them. Many companies use more than one, and the integration layer hides the difference from the ERP.

Read more: ERP and banksLink to this question

Where the bank offers both, camt.053 carries richer, structured remittance data, which makes automatic matching more reliable. MT940 is still widely used and works well for many cases. We can take both, convert them into the same internal model, and move each bank from MT940 to camt.053 when it suits you and the bank.

Read more: ERP and banksLink to this question

Usually as events close to real time, because stock and sales figures are then current during the day. Some ERPs or licences make frequent postings costly, so the layer can also group events into summaries per store and period. We choose with you based on what decisions need current data and what the ERP handles well.

Read more: POS and ERPLink to this question

The design works with any POS that can export transactions through an API, events or files, and with ERPs such as SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central and Odoo. We confirm the interfaces of your specific POS and ERP at the start. Naming a product does not mean a partnership with its vendor.

Read more: POS and ERPLink to this question

The acquirer is the bank or licensed institution that processes card payments for you and pays out the money. The gateway is the technical service in front of it that accepts requests from terminals and checkouts, tokenises cards and routes them. Some providers are both. The design works either way and keeps the two roles clear.

Read more: Card paymentsLink to this question

No. ISO 8583 defines a structure, and each acquirer or network publishes its own specification of fields, message types and codes. That is why we build from the acquirer’s specification and run its certification tests. A gateway API in front of the acquirer hides these differences, which is often simpler for retailers.

Read more: Card paymentsLink to this question

An aggregator gives you many banks through one API and handles each bank’s differences, at a per-call or per-connection cost. Direct connections give more control and can suit a small number of important banks. Many products start with an aggregator and add direct connections later. We compare the options against the banks and countries you need.

Read more: Open banking APIsLink to this question

Coverage depends on the region’s rules and the banks’ APIs. The European Union and the United Kingdom have broad coverage under PSD2 and the UK Open Banking Standard. Elsewhere coverage varies, and aggregators fill some of the gaps. We check coverage for the banks your customers use before you commit to a design.

Read more: Open banking APIsLink to this question

Not for most corporate treasury work. Host-to-host channels handle bulk payment files and full statements for your own accounts. Open banking suits customer-facing products, real-time balances and single payments. Many businesses use both: host-to-host for their own payment runs and open banking for their customers.

Read more: Open banking APIsLink to this question

Any service with a documented API or file interface. Typical examples are CRM platforms, carriers and logistics providers, marketplaces, e-invoicing and tax platforms, payroll, KYC and identity providers, and trading partners who exchange EDI documents over AS2. We review each partner’s API, limits and test environment before we commit to a plan.

Read more: ERP and third partiesLink to this question

Once several partners are connected to one ERP, a platform such as MuleSoft, Boomi or Azure Logic Apps, or a set of custom services built on a message queue, keeps mapping, retries and monitoring in one place. With one or two partners, direct connections can be enough. We set out the trade-offs, including licence costs, for your case.

Read more: ERP and third partiesLink to this question