Security and Architecture

Security Designed Into the Payment Architecture

Protect payment operations through tokenization, controlled access, infrastructure separation, secure credential handling, and deployment models aligned with your security requirements.

Discuss Security Requirements Explore Deployment Options
transaqo · security architecture
01CheckoutCustomer-facing collection and payment flow
02Tokenization or vaultEligible credentials handled through the selected model
03Transaqo orchestrationRouting, connector configuration, and payment operations
04Connected providersProcessing under the client’s provider arrangements
Identity and accessUsers, teams, merchants, and administrative permissions
Secrets and credentialsProvider keys, connector settings, and controlled operational access
Infrastructure and networkDeployment-specific boundaries, certificates, databases, and backups
Monitoring and operationsPayment events, failures, provider performance, and escalation contacts

The applicable controls and responsibilities are defined for the complete production architecture and selected deployment model.

Architecture Before Labels

Security is defined by the complete payment flow.

Payment security is not created by adding one feature or certification to an otherwise undefined system. It depends on how data is collected, where sensitive information travels, which vault is used, who controls the infrastructure, how credentials are protected, and who can administer the environment.

01

Checkout and collection

Determine where payment information enters the architecture and which systems receive or transmit it.

02

Vault and tokenization

Select the appropriate managed, client-hosted, or supported external-vault configuration.

03

Infrastructure ownership

Define whether the environment is managed, dedicated, private-cloud, or client-hosted.

04

Credential handling

Control how provider keys, connector credentials, and secrets are stored and accessed.

05

Administrative access

Separate platform, merchant, business-profile, and team permissions according to responsibility.

06

Operating responsibilities

Agree monitoring, backups, updates, incident contacts, and production support for the selected service.

Reduce Exposure Through Tokenization

Keep raw payment credentials out of unnecessary systems.

Use an appropriate vault configuration to tokenize eligible payment credentials. The correct model depends on the payment flow, deployment preference, existing data environment, and compliance responsibilities.

InputEligible credential

Collected through the selected checkout architecture.

Vault modelTokenization

Managed, client-hosted, or supported external configuration.

ReuseEligible token

Used within supported recurring or returning-customer flows.

Protect Provider Credentials

Handle connector access as production infrastructure.

Payment-provider API keys and other connection credentials require controlled storage, restricted access, and operational procedures appropriate to the selected deployment.

Provider credential boundaryProduction configuration
StorageUse suitable secrets-management and encryption arrangements for the production environment.
AccessLimit sensitive connector settings to authorized users and operational roles.
UseApply credentials only to the relevant provider connection, merchant, or business profile.
OperationsDefine procedures for configuration, updates, support, and incident handling.

Operational rule: production credentials should not be shared through ordinary email or unprotected documents.

Separate Test and Production Operations

Validate payment flows without using live credentials.

Test Mode enables teams to explore the platform and validate supported scenarios in a non-production environment. Production is configured separately with the applicable provider accounts, infrastructure, user permissions, credentials, and operational contacts.

Non-production

Test Mode

  • Test credentials and provider sandboxes
  • Supported payment-scenario validation
  • Dashboard and operational-flow review
  • No automatic production activation
Production

Production Environment

  • Approved provider accounts and live credentials
  • Defined infrastructure and security responsibilities
  • Production permissions and operational contacts
  • Implementation-specific activation process

Access Control and Merchant Isolation

Match visibility and administration to operational responsibility.

Account and role structures can separate organizations, merchants, business profiles, and team members. In multi-merchant environments, the hierarchy can preserve platform-level oversight while limiting access to the configuration and information relevant to each user.

  • Separate merchant accounts and API credentials
  • Apply business-profile payment settings
  • Limit routing and provider configuration access
  • Separate platform and merchant-level visibility
Platform environmentControlled oversight
OrganizationPlatform teamEnvironment-wide operational and configuration responsibilities.
Merchant profileMerchant teamAccess to the transactions, providers, and settings relevant to that profile.
Specialist roleTechnical or support userLimited access aligned with integration, investigation, or support duties.

Data in Transit and at Rest

Protect each boundary in the selected deployment.

Production environments should protect data as it moves between customer applications, Transaqo, connected providers, databases, backups, and other services. The detailed controls depend on who operates the infrastructure and where sensitive information is collected, transmitted, tokenized, or stored.

Encryption, certificate management, network policies, database protection, backups, and key management should be defined for the complete architecture rather than assumed from the software alone.

01Customer application

Checkout and integration boundary.

02Transaqo environment

Orchestration, operational settings, and connector layer.

03Connected services

PSPs, acquirers, vaults, and other selected providers.

04Operational data

Databases, logs, backups, and monitoring systems.

Transport controlsCertificates, secure connections, and network policy appropriate to the environment.
Stored-data controlsDatabase, backup, secret, and key-management arrangements defined for the deployment.
Infrastructure controlsManaged, dedicated, private-cloud, or client-hosted responsibilities.

Operational Visibility

Bring payment and infrastructure signals into the operating model.

Centralized monitoring can help teams identify processing issues, configuration errors, provider disruptions, and unusual operational patterns. The applicable monitoring and incident-response arrangements depend on the selected service and deployment.

A production setup may include payment-event visibility, provider-performance monitoring, error analysis, controlled administrative access, backup procedures, and defined escalation contacts.

transaqo · operational visibilityArchitecture-dependent
Payment events

Centralized visibility into supported transaction outcomes and processing states.

Observed
Provider performance

Operational review of availability, errors, and provider-specific disruptions.

Reviewed
Configuration changes

Controlled administrative access to sensitive operational settings.

Controlled
Recovery procedures

Backup, recovery, and escalation arrangements defined for the selected service.

Defined

Understand the Compliance Boundary

Software alone does not determine every organization’s obligations.

PCI DSS scope and other requirements depend on the complete payment architecture: checkout implementation, card-data handling, vault selection, hosting, connected providers, operational access, and contractual responsibilities.

Client responsibilities

Business and compliance assessment

Assess the client’s legal, regulatory, contractual, and operational obligations for the intended payment model and environment.

Transaqo role

Technical responsibility model

Define how the selected platform, integration, deployment, access, credential, and operating responsibilities are divided for implementation.

Provider and service scope

Entity-specific attestations

Attribute certifications or attestations only to the specific provider, service, entity, or environment to which they apply.

Transaqo can help define the technical responsibility model for the selected deployment, but does not replace the client’s own legal, regulatory, or compliance assessment. No certification or attestation is claimed on this page.

Production Architecture

Define a Secure Production Architecture

Discuss your checkout model, vault requirements, infrastructure controls, and operational responsibilities before moving into production.

Discuss Security Requirements Request an Architecture Review