Payment integrations do not always use a single API key in the literal sense. Some providers use client IDs, secrets, certificates, or OAuth. The security principle remains the same: only the appropriate applications and people are granted the minimum necessary access.
Do not include production keys in browser JavaScript, mobile app bundles, public repositories, or widely shared documents. In principle, anything delivered on the client side can be read.
Use a server-side secret manager or a secure environment configuration with restricted access.
A sandbox and a production environment must use different credentials and endpoints. Test data should not appear in production reports, and a test key must not be able to process actual refunds or payments.
Make the environment visually recognizable to minimize errors during development.
Are you unsure whether to choose a plugin or an API? Then read on to find out how to choose the right one chooses a plugin or API.
Grant an integration only the scopes it needs. An application that reads payment statuses may not need to be allowed to process refunds or make account changes. Where possible, restrict the allowed IP addresses, domains, or merchants.
Use separate credentials for each application or vendor so that access can be revoked on a targeted basis.
When creating a link, it's important that you Securely connect your cash register to your payment terminal or payment API is linked.
Update credentials in accordance with the provider’s policy and immediately upon suspicion of a breach, a change in personnel, or the expiration of a supplier contract. Test rotation without extended downtime by temporarily overlapping old and new credentials in a controlled manner, if the provider supports this.
Record the owner, creation date, rights, and scheduled expiration date without entering the value itself in the registry.
Logs may contain references, timestamps, and error codes, but must not include PINs, full card details, or secrets. Mask tokens and sensitive headers. Limit the retention period and access.
Monitor unusual activity, a high number of failed authentication attempts, and unexpected refund requests.
API security is not a one-time setup. It requires an inventory, minimal permissions, secure storage, monitoring, and a plan for rotation and incidents.
More about a safe Payment API and POS integration You can read more in our guide to integrations.
OmEs pay coordinates the provider configuration with your developer. The developer remains responsible for secure storage and application code; together, we test the agreed-upon payment flow.
