Integration access

Confirm the services your integration needs, how each merchant account is identified and which operations your application may perform. Request the documentation and access instructions before connecting your system.

Developers and administrators

Before you begin

The services and operations your integration needs
The business and account references already available to your team
Contacts for engineering and payment operations

On this page

Map your connections

Start with the access your business needs. Hosted account tools and API access are separate choices. A portal login does not grant API permissions, and reporting access does not automatically permit refunds, adjustments or funding instructions.

Account and integration responsibilities

Account serviceApplication accessProgram and environment
Checkout servicePayment accessProcessing account and environment
Reporting serviceRecord accessAccount access and permissions

Confirm the connections assigned through the merchant account service. Keep server credentials out of the customer interface.

Account and environment: Record the business, merchant account references and whether the connection is for sandbox or production.
Access and contacts: Record the permitted operations, documentation version and the person responsible for the connection.

Keep account identities distinct

Keep your business record connected to the account identifiers supplied for your integration. An application, processing merchant, reporting account and portal user can have different identifiers. Record only the account scopes used by your connection.

Resolve access on your server
Start from the authenticated user and your own business record. Determine the permitted merchant and operation before making an external request.
Check the returned account
Compare the response with the expected merchant mapping. Do not display a record from a different merchant, even when the API request itself succeeded.

Account mapping
Record	How to use it
Your business ID	Your stable identifier for the business using your platform. On your server, check whether the user who is signed in has access to it.
Application and program	The application reference and any program identifier assigned to it. Keep the review decision and setup results with that application.
Processing account	The merchant or organization identifiers assigned for processing. Keep distinct identifiers separate where the integration requires more than one.
Reporting account	The account or tenant that controls reporting access and the merchant whose records may be read. Confirm the account references in your integration documentation.
Environment	Keep a separate mapping for sandbox and production. A matching label or identifier is not evidence that the two environments are interchangeable.

What to confirm

Changing a merchant ID in a browser request cannot change which account that user is authorized to access.

Protect credentials and permissions

Store secrets in your backend’s protected configuration. Keep them out of browser bundles, URLs, analytics and application logs. Use credentials only for their assigned service and environment.

Account setup: Use only the credentials and permissions assigned to the application or account connection.
Checkout: Follow the access instructions supplied through your merchant account service. Keep server credentials out of the customer interface.
Reporting: Confirm which merchant records may be read and which operations, if any, may be submitted.

Rotate or revoke a key

Use the authorized process for managing keys. Verify the replacement in the correct environment before retiring an uncompromised old key. If a secret is exposed, restrict affected access and follow the incident procedure. Send only the key identifier in a support request, never its secret value.

Keep webhook security separate

Incoming events may use separate verification keys or encryption settings. Follow the event documentation; an outbound API credential does not authenticate an incoming notification.

Verify access before changing records

Start by checking the account as described in your integration documentation, without changing its information. The response must belong to the intended merchant, and access to another merchant’s records must be refused. Ask our integration team for the account lookup and permission checks before connecting your system.

Request the response definitions, lookup procedures and retry rules from our integration team. Do not infer a business outcome from an HTTP status alone.

Verify access and outcomes
Check	What to establish
Identity	The connection returns the records for the intended merchant and environment.
Permissions	Access outside the assigned merchant or permitted operation is refused.
Request acceptance	A successful connection or accepted request is distinguished from the application decision or payment result.
Uncertain operation	An operation with an uncertain result can be traced using its original reference before another attempt.

Keep the integration record current

Connection details: Record the permitted operations, documentation version, website origins, enabled payment methods and payment completion settings.
Identity and permissions: Confirm the account mappings used by your connection and who may read records or perform each operation.
Events and recovery: Record any subscribed event types, required verification or encryption, retry rules and the payment lookup used to resolve an uncertain result.
Support contacts: Assign contacts for credential incidents, payment uncertainty, refunds, disputes and funding questions. Keep the connection record current when access changes.