TRUST & RESPONSIBILITY
Keep payment operations controlled and auditable.
Protect the technical layer with explicit access, preserved evidence and clear responsibility boundaries across merchant, PayStar and PSP.
Security is not a badge detached from the payment flow. Teams need to understand where sensitive data travels, who can act, what is recorded and which organisation owns each decision.
[01] security properties the operating model must preserve
Security properties the operating model must preserve
Clear scope and data boundaries
Minimise unnecessary exposure, keep payment credentials out of public channels and document where provider-specific data enters the lifecycle.
Role-based operating access
Give payment, support, finance and technical roles the access required for their job while keeping privileged actions attributable.
Evidence for investigation and audit
Preserve normalized events, original PSP responses, callbacks and authorized corrections as one traceable operating history.
Monitoring and response ownership
Detect technical degradation, identify the responsible system and coordinate the next action without confusing platform availability with PSP approval.
Contract-backed service availability
PayStar commits to a 99.5% service availability SLA. Financial responsibility if this service level is not met is defined directly in the contract.
[02] responsibility does not disappear behind the platform
Responsibility does not disappear behind the platform
The merchant owns provider selection, commercial terms and routing policy. PayStar owns the technical orchestration layer. Each PSP remains responsible for processing and settlement under its direct contract.
[03] Data flow
Trace the data through the payment lifecycle
Review the actual request, provider interaction, callback and reporting paths for the payment method you plan to use. Identify which party receives each data field and which team owns the next action. The data scope follows the selected integration and supported operations.
Direct Connect provides the merchant-facing API and provider adapters. Core connects routing policy, attempt history, callbacks and provider evidence into the operating context used for investigation and reconciliation. The merchant retains its provider contracts and routing policy; each PSP owns processing and settlement under its agreement.
Use the API integration guide to review the technical flow, and the reconciliation overview to distinguish payment events from provider reports and expected settlement. Confirm hosting and data locations, retention and the relevant service providers for your specific setup during the integration review.
[04] Access boundaries
Separate pipeline credentials from operating permissions
Each Direct Connect pipeline has its own access key. Two deposit pipelines use different keys, and deposit and payout access do not share a key. Review the required operations and the scope of each pipeline with your integration team.
Review human access separately: who may inspect payment details, change routing policy, perform an authorised correction or resend a callback, and who approves those actions. Use the PayOps workflow to walk through the permitted actions and the record of who changed what and why.
Keep passwords, access keys and full payment credentials out of public channels and incident messages. For an investigation, start with the affected service, event time and time zone, available transaction identifiers and redacted error examples.
[05] Evidence review
Evidence to review for your integration
Use this inventory to identify the documents and records needed for your setup. Confirm their availability, applicable scope and permitted disclosure with our team.
Service and data-flow map
Identify the products, PSPs and pipelines in use, the request and callback paths, data locations and the parties handling each part of the flow. Include the applicable retention and service-provider arrangements.
Access and action ownership
Record the pipeline credential boundaries, human roles, privileged actions and approval owners relevant to the integration. Review operational permissions separately from API credentials.
Payment and change history
Use the relevant transaction identifiers, routing context, attempts, normalised results, original PSP responses and callbacks. For an authorised correction or recovery action, review who acted, what changed and why.
Assessment record and history
For each assessment, record the document version, assessed entity and environment, scope, assessment date, assessor and result. Check how that assessment applies to the service being evaluated and whether later changes affect its relevance.
Incident record
Bring together the affected services, event times, monitoring evidence, reported symptoms, customer-chat updates and the agreed next owner. Review observations that differ from PayStar monitoring with the supporting evidence.
Certification status, service levels and other assurances should identify their scope, current source, date and accountable owner. General website language should not be treated as a substitute for contractual evidence.
PCI DSS & AOC ↗ — Review assessment information and request the Attestation of Compliance for your evaluation.
[06] Worked example
Example: investigating a pending payment
This is an illustrative review scenario, not a customer case or a promised outcome.
The merchant identifies the affected payment, provides the available identifiers and event time, and describes the expected result.
The payment team compares the recorded attempts, normalised status, original PSP response and callbacks to locate the unresolved step.
The responsible team takes a permitted next action or prepares a PSP escalation with the relevant evidence. Provider decisions and settlement remain with the PSP.
Any authorised correction or recovery step stays connected to the payment history so the next person can understand what changed and why.
[07] Incident ownership
Coordinate incidents with a clear owner
PayStar monitoring is the default source of service-availability and outage-duration data. Customers are notified in the agreed working chat of outages affecting their services, with progress updates and the current estimate for service restoration. Estimates are refined as the investigation progresses.
Incident handling is available 24/7, incurs no additional fee and does not consume the standard support-hour allowance. Report an incident in the agreed working chat or call your PayStar manager; share the available details without waiting for a complete investigation.
The SLA and incident support overview explains the service-credit principle and different levels of impact. The applicable agreement defines the covered services, measurement rules, exclusions and compensation terms.
[08] Review and contact
Review scope and contact
Bring your selected product, PSPs, payment methods and the security or onboarding questions your team needs to resolve. Use the contact details on this page to arrange a review of the relevant technical and operational boundaries.
Content reviewed: 20 September 2026. This is the review date of the page content, not the date of a security assessment.