Security And Operations

This integration should be operated as a payment-critical backend service.

It handles transaction lifecycle events, potentially sensitive card data, and, in some programs, authorization decisioning. Security, availability, and operational control should therefore be treated as production-critical requirements rather than optional hardening measures.

Security baseline

At a minimum, the operating model should enforce:

• TLS for all API and webhook traffic
• strict separation between sandbox and production environments
• controlled access to credentials, keys, and operational tooling
• auditable logging for requests, decisions, and state changes
• restricted operator access to payment-sensitive systems and records

Security controls should be implemented as part of the production operating model, not added later as compensating measures.

Sensitive data protection

If card data is retrieved, stored, decrypted, displayed, or transmitted, that handling must remain within the applicable compliance and security perimeter for the program.

At a minimum:

• sensitive card data must not be written to logs
• exposure of sensitive values across internal systems should be minimized
• access to payment-sensitive data must be limited to authorized systems and personnel
• decryption keys and related cryptographic material must be handled through controlled and secure key-management processes

Credential and key management

Authentication credentials and encryption keys should be handled as controlled secrets.

At a minimum:

• store credentials and keys only in approved secret-management systems
• never embed them in source code, client-side applications, or logs
• separate sandbox and production credentials completely
• rotate and replace credentials through a controlled operational process
• ensure operational teams can revoke or replace credentials quickly when required

Where FINCI exposes sensitive card data, the integrator must also provide the required public key material for encryption and manage that key material through controlled operational processes.

Operational monitoring

Operational teams should be able to detect degraded performance, decisioning failures in programs that use integrator-managed authorization, and transaction-processing issues quickly.

Monitoring should cover at least:

• webhook delivery latency
• authorization timeout rate
• approval and decline outcomes
• repeated or duplicate event delivery
• clearing and posting failures
• card status or lifecycle update failures

Operational telemetry should support transaction tracing from authorization through presentment and any later reversal or return.

Resilience and incident response

The operating model should support safe recovery and controlled incident handling.

At a minimum, the integration team should be able to:

• rotate or revoke credentials and keys
• isolate or disable affected flows safely
• investigate a transaction end to end
• identify failed or repeated webhook processing
• repair or replay asynchronous processing when required

Shared responsibility boundary

FINCI owns the issuing platform and network connectivity layer.

In integrator-operated programs, the integrator remains responsible for:

• its own application availability
• internal controls and access management
• authorization decision logic in integrator-managed decisioning setups
• ledger or reconciliation handling when retained by the integrator
• secure processing of API traffic and webhook traffic
• operation of its own monitoring, incident handling, and support processes

Where a program uses a different responsibility split, the documented program setup should take precedence.