Integrations with platforms such as Stripe, Shopify, and Salesforce are often where business-critical data and money move between systems. They are also where shortcuts are common: an API key pasted into front-end code, a webhook endpoint that accepts any request, or a sync job that silently fails. Each provider publishes detailed security guidance, but the integration code your team writes is still your responsibility. This guide covers the practical controls that make integrations safer and more reliable.
What It Is
A secure integration protects three things: the credentials that grant access, the data that flows between systems, and the integrity of the business events that trigger actions. Credentials include API keys, OAuth tokens, and client secrets; they should live only on the server, in a secrets manager or protected environment configuration, with the narrowest permissions the integration needs. Data in transit uses HTTPS, and data at rest is limited to what the business actually needs to store. Event integrity depends on verifying that inbound webhooks really come from the provider. Stripe, for example, signs webhook events with a signing secret and provides a signature header that your endpoint should verify; Shopify signs webhooks with an HMAC header; Salesforce integrations typically rely on OAuth through a connected app or its newer equivalent, an external client app, with scoped permissions. Reliability matters too. Webhooks can arrive late, more than once, or out of order, so handlers should be idempotent, and outbound calls should handle rate limits and retries without duplicating charges, orders, or records. Stripe supports idempotency keys for this reason.
Who It Is For
This guide is aimed at:
- Teams connecting payments, subscriptions, or checkout flows to their own systems
- E-commerce businesses syncing orders, inventory, or customers between Shopify and other platforms
- Companies integrating CRM data from Salesforce with internal tools or customer portals
- Product owners reviewing integration work delivered by an agency or freelancer
What It Helps Clarify
Working through the controls helps clarify:
- Where credentials are stored, who can access them, and how they are rotated
- Whether webhook endpoints verify signatures and reject unsigned or replayed requests
- How failures, retries, and duplicates are handled without corrupting data
- Which data is copied between systems, and whether it all needs to be
What's Included
- Keep secret API keys server-side only; use publishable or public keys in clients where the provider supports them
- Store secrets in a secrets manager or protected configuration, never in source code repositories
- Request the narrowest scopes and permissions; use separate credentials per environment
- Rotate credentials on a schedule and immediately after staff or supplier changes
- Verify webhook signatures using the provider's documented method and reject requests that fail
- Check event timestamps to reduce replay risk, and record processed event IDs
- Make handlers idempotent so repeated events do not create duplicate actions
- Use idempotency keys or equivalent safeguards on outbound create operations where supported
- Handle rate limits with backoff and queue work rather than dropping it
- Log integration events without logging secrets, card data, or unnecessary personal data
- Alert someone when sync jobs or webhooks fail repeatedly
- Test in provider sandbox or test modes before switching to live credentials
What's Not Included
- PCI DSS compliance validation or payment-processor approval
- Fraud operations or chargeback management
- A claim that following these controls prevents every integration incident
- Operation of third-party platforms, which remain the providers' responsibility
When to Choose It
Use this checklist when designing a new integration, before go-live, when inheriting integration code from another team, and after any incident involving duplicate payments, missing orders, or unexpected data access. It is particularly important when an integration can trigger financial actions, such as charges, refunds, or subscription changes, or can expose customer records.
Our Approach
Treat each integration as a small product with its own owner, documentation, and monitoring. Start with an inventory of integrations, credentials, and webhook endpoints; many organisations discover keys nobody remembers creating. Then apply the controls above in order of risk: secrets and signature verification first, then idempotency and failure handling, then logging and alerting. Our Secure Backend & API Engineering service designs and delivers backend and integration work with an API contract, test summary, and operations runbook, with production access and customer data used only under explicit written authorisation. Where payment and subscription logic is involved, Subscription & Payment Infrastructure Security can review the agreed payment and entitlement paths separately. If you want an independent check of existing integration endpoints, an application security review can include them in scope.
Frequently Asked Questions
Related Articles
Get Started
Planning or reviewing a business-critical integration?
Share the platforms involved, the data and events that flow between them, and any issues you have seen. We will propose a written scope.
Request a written scope