Integrations and industries

Each integration uses its own technical account with only the permissions its flows need, never a person’s login. Credentials live in your secrets store, not in code. Our engineers work in test systems with masked or sample data where possible, and their access is named, logged and removed when they leave the project.

Read more: ERP integrationLink to this question

Payment files are signed and encrypted as each bank requires, for example with OpenPGP, and travel only over the agreed channel. Keys and certificates are kept in your key vault or hardware security module, never in code, and only named people can reach them. Files are validated before they are sent, and every transfer is logged, so you can trace who approved and sent each payment.

Read more: Bank integrationLink to this question

We cannot remove PCI DSS, but we can reduce how much of your estate it applies to. We use hosted payment pages, point-to-point encryption at the terminal and tokens from the gateway, so card numbers never reach your POS, ERP or data warehouse. We document the data flows so your assessor can see which systems handle card data and which do not.

Read more: Payments and POS integrationLink to this question

Yes. We add single sign-on with OpenID Connect or SAML 2.0 through providers such as Microsoft Entra ID or Keycloak, and provision users automatically with SCIM where the application supports it. Services call each other with OAuth 2.0 tokens scoped to what each needs. Your identity provider stays the single place where access is granted and removed.

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

Yes. We work inside your policies: your access rules, your environments, your change process and your audit requirements. Before work starts we agree how data is handled, which environments engineers may reach, and what evidence your risk and compliance teams need. We describe the controls we apply plainly, so your assessors can review them.

Read more: Fintech and financial servicesLink to this question

We design so that as few systems as possible ever see a full card number. Hosted payment fields, tokenisation and network tokens keep card data with the processor, which reduces your PCI DSS scope. Where a system must handle card data, we build it to the PCI DSS controls that apply and document them for your assessor.

Read more: Fintech and financial servicesLink to this question

We collect only the data a feature needs, keep it in the region and environment you choose, and encrypt it in transit and at rest. Access follows roles and is logged. Our engineers work with synthetic or de-identified data wherever possible, and with real data only with your approval and under your supervision.

Read more: HealthcareLink to this question

Compliance belongs to your organisation and to how it operates a system, so no software supplier can make you compliant on its own. What we do is design and build to the requirements that apply, document the controls, and support your privacy and security teams in their assessments.

Read more: HealthcareLink to this question

Where your rules say. We work with government or sovereign cloud regions, approved commercial clouds or your own data centres, and we design the system so that you make the hosting decision. Backups, logs and support access follow the same rule, because data often leaves a region through them rather than through the application.

Read more: Public sectorLink to this question

Yes. Approval stays in your ERP with its existing controls. The integration layer logs every file it creates, signs, sends and receives, with timestamps, identifiers and the technical account used. That log links each payment in the bank’s status report back to the ERP document and its approvers.

Read more: ERP and banksLink to this question

That is the aim of the design. Card numbers are captured by the certified terminal or a hosted payment page and replaced by tokens at the gateway, so your POS, ERP and data stores only ever see tokens. This reduces the part of your estate that PCI DSS applies to. Your assessor confirms the final scope.

Read more: Card paymentsLink to this question

Yes. For online card payments we integrate EMV 3-D Secure through the gateway, so the issuer can authenticate the cardholder where regulation or risk requires it. We handle the challenge and frictionless flows in the checkout and test both with the provider’s test cards.

Read more: Card paymentsLink to this question

The customer sees what data is shared, for what purpose and for how long, and authenticates with their own bank. The connector stores the consent and its tokens encrypted, and every call is tied to a valid consent. Customers can withdraw consent, and the connector stops calling that bank for them when they do.

Read more: Open banking APIsLink to this question

Tokens and consent records are encrypted at rest, only the connector can use them, and every call is logged with the consent behind it. We collect only the data the purpose needs and set how long it is kept. Data protection rules such as GDPR apply to this data, and we design with your data protection officer.

Read more: Open banking APIsLink to this question

Every incoming webhook is verified before it is processed: by signature where the partner signs its messages, and by token, source and timestamp checks where it does not. Payloads are validated against the contract, and events are processed once even if the partner sends them more than once.

Read more: ERP and third partiesLink to this question