Security at Omise

Omise is committed to safeguarding sensitive customer information with industry-leading security practices, compliance certifications, and continuous security monitoring.

Overview

As a payments infrastructure provider, security is fundamental to everything we do. We implement multiple layers of protection to ensure your customers' payment data remains secure throughout the transaction lifecycle.

Key Security Highlights:

• PCI DSS Level 1 certified (highest level)
• NIST Cybersecurity Framework compliant
• AES-256 encryption for data at rest
• TLS 1.2+ for data in transit
• 24/7 security monitoring
• Regular third-party penetration testing

Compliance & Standards

PCI DSS Level 1

Omise maintains PCI DSS Level 1 certification, the highest level of payment card industry compliance. This certification requires:

• Annual on-site assessment by a Qualified Security Assessor (QSA)
• Quarterly network scans by Approved Scanning Vendor (ASV)
• Comprehensive security controls across all systems
• Regular penetration testing and vulnerability assessments

Verify our certification:

• Visa Global Registry of Service Providers
• Mastercard SDP List

What This Means for You

When you use Omise, card data never touches your servers. This significantly reduces your PCI compliance scope - typically to SAQ A (the simplest self-assessment questionnaire).

NIST Cybersecurity Framework

We adhere to the National Institute of Standards and Technology (NIST) Cybersecurity Framework, which provides guidelines for:

• Identify - Asset management and risk assessment
• Protect - Access controls and data security
• Detect - Continuous monitoring and anomaly detection
• Respond - Incident response procedures
• Recover - Business continuity planning

Data Protection Regulations

Omise complies with regional data protection laws:

Region	Regulation	Requirements
Thailand	PDPA	Personal Data Protection Act compliance
Singapore	PDPA	Personal Data Protection Act compliance
Japan	APPI	Act on Protection of Personal Information
EU/EEA	GDPR	General Data Protection Regulation (where applicable)

Our data protection practices:

• Data minimization - We only collect what's necessary
• Purpose limitation - Data used only for stated purposes
• Retention policies - Automatic deletion after required period
• Right to erasure - Support for data deletion requests
• Breach notification - Prompt notification if incidents occur

Product Security

Multi-Factor Authentication (MFA)

All dashboard accounts support MFA:

• TOTP apps - Google Authenticator, Authy, etc.
• SMS codes - Backup verification method
• Hardware keys - YubiKey and similar devices (enterprise)

Enable MFA

We strongly recommend enabling MFA for all team members with dashboard access. Go to Settings > Security > Two-Factor Authentication.

Role-Based Access Control (RBAC)

Control team access with granular permissions:

Role	Capabilities
Owner	Full access, manage team, billing, API keys
Admin	Manage settings, view all data, process refunds
Developer	Access API keys, view test transactions
Support	View transactions, limited refund capability
Finance	View reports, settlements, no API access
Read-only	View-only access to dashboard

Audit Logging

All account activity is logged:

• Login attempts (successful and failed)
• API key creation and deletion
• Configuration changes
• Refund and void operations
• Team member changes
• Permission modifications

Access audit logs in Dashboard > Settings > Activity Log.

Session Security

• Automatic session timeout after inactivity
• Concurrent session limits
• Session revocation capability
• IP-based session validation (optional)
• Secure cookie handling (HttpOnly, Secure, SameSite)

Data Security

Encryption

Data at Rest:

• AES-256 encryption for all stored card data
• Encrypted database backups
• Hardware Security Modules (HSMs) for key management
• Key rotation policies

Data in Transit:

• TLS 1.2 minimum (TLS 1.3 supported)
• Perfect Forward Secrecy (PFS)
• Strong cipher suites only
• HSTS enforcement

Supported TLS Cipher Suites:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

Tokenization

Card numbers are replaced with randomly-generated tokens:

Card Number: 4242 4242 4242 4242
     ↓ Tokenization
Token: tokn_test_5xuy4w91xqz7d1w9u0t

Token characteristics:

• Single-use by default
• Merchant-specific (cannot be used elsewhere)
• Time-limited validity
• No reversible relationship to card number
• Stored separately from card data

Card Data Isolation

Isolation measures:

• Separate network segment for card data
• Restricted access (need-to-know basis)
• No direct database access
• All access through APIs
• Comprehensive logging

Infrastructure Security

Network Security

• Firewalls - Multi-layer firewall protection
• DDoS Protection - Automatic attack mitigation
• WAF - Web Application Firewall for API protection
• IDS/IPS - Intrusion detection and prevention
• Network Segmentation - Isolated production environments

Server Security

• Regular OS security patching
• Hardened server configurations
• Minimal installed packages
• Disabled unnecessary services
• Regular vulnerability scanning

Mutual TLS (mTLS)

Server-to-server communication uses mutual TLS:

• Both client and server present certificates
• Prevents man-in-the-middle attacks
• Additional authentication layer
• Used for internal service communication

Development Practices

Secure Development Lifecycle (SDL)

Security is integrated throughout our development process:

1. Design - Security review of architecture
2. Development - Secure coding standards
3. Code Review - Multi-party review required
4. Testing - Automated security testing
5. Deployment - Secure deployment pipeline
6. Monitoring - Runtime security monitoring

Code Security

• Static Analysis - Automated code scanning (SAST)
• Dynamic Testing - Runtime vulnerability testing (DAST)
• Dependency Scanning - Third-party library checks
• Container Scanning - Docker image security
• Secret Detection - Prevent credential leaks

Vulnerability Management

• Regular vulnerability assessments
• Prioritized remediation based on risk
• Patch management policies
• Third-party penetration testing (annual)
• Continuous monitoring for new vulnerabilities

Bug Bounty Program

We partner with HackerOne for responsible security research:

In Scope:

• api.omise.co
• vault.omise.co
• dashboard.omise.co
• cdn.omise.co
• Omise mobile SDKs

Rewards:

• Critical vulnerabilities: Up to $5,000
• High severity: Up to $2,000
• Medium severity: Up to $500
• Low severity: Up to $100

Report vulnerabilities: security@omise.co or via HackerOne

Responsible Disclosure

Please do not publicly disclose vulnerabilities until we've had time to address them. We aim to respond within 24 hours and resolve critical issues within 7 days.

Corporate Security

Employee Security

• Background checks for all employees
• Security training during onboarding
• Monthly security awareness sessions
• Simulated phishing campaigns
• Clear desk and screen policies

Access Management

• SSO (Single Sign-On) for all systems
• Hardware-based 2FA for employees
• Principle of least privilege
• Regular access reviews
• Immediate revocation on termination

Physical Security

• 24/7 security monitoring
• Access card entry systems
• CCTV surveillance
• Visitor management
• Secure document disposal

Incident Response

Response Process

1. Detection - Automated monitoring and alerting
2. Triage - Assess severity and impact
3. Containment - Limit damage and prevent spread
4. Eradication - Remove threat from systems
5. Recovery - Restore normal operations
6. Post-Incident - Analysis and improvements

Communication

In the event of a security incident affecting your data:

• Notification within 72 hours (or as required by law)
• Clear description of what happened
• Steps we're taking to address it
• Recommendations for your response
• Ongoing updates until resolution

Contact

Security Team: security@omise.co

For urgent security matters, include "URGENT" in the subject line.

Security Best Practices for Merchants

Protect Your API Keys

# DO: Use environment variables
export OMISE_SECRET_KEY="skey_live_..."

# DON'T: Hardcode in source code
const secretKey = "skey_live_..." // NEVER DO THIS

Enable All Security Features

1. Enable MFA - For all team members
2. Use Role-Based Access - Minimum necessary permissions
3. Review Audit Logs - Regularly check for anomalies
4. Implement Webhooks - Monitor transaction events
5. Enable 3D Secure - For card transactions

Secure Your Integration

• Use HTTPS everywhere (TLS 1.2+)
• Validate webhook signatures
• Implement CSRF protection
• Use Content Security Policy
• Keep libraries updated
• Don't log sensitive data

Monitor for Fraud

• Review high-risk transactions
• Set up fraud alerts
• Monitor chargeback rates
• Implement velocity checks
• Use address verification (AVS)

Compliance Documentation

Request compliance documentation for your records:

Document	Purpose	How to Obtain
PCI AOC	Attestation of Compliance	Contact support
SOC 2 Report	Service Organization Controls	Contact support
Security Questionnaire	Vendor assessment	Contact support
Data Processing Agreement	GDPR compliance	Dashboard settings

FAQ

Is Omise PCI compliant?

Yes, Omise is PCI DSS Level 1 certified, the highest level of PCI compliance. This is validated annually by a Qualified Security Assessor (QSA).

Do I need PCI certification to use Omise?

When using Omise.js or our mobile SDKs, card data never touches your servers. This typically reduces your PCI scope to SAQ A (the simplest self-assessment). Consult with your QSA for your specific situation.

How is card data protected?

Card data is encrypted with AES-256, stored in an isolated environment, and protected by multiple security layers. Card numbers are tokenized so your systems never see actual card numbers.

What happens if there's a security breach?

We have comprehensive incident response procedures. Affected parties would be notified within 72 hours with details about the incident and recommended actions.

How do I report a security vulnerability?

Email security@omise.co or submit through our HackerOne program. Please allow us time to address the issue before public disclosure.

Is MFA required?

MFA is strongly recommended but not required by default. Organizations can enforce MFA for all team members through dashboard settings.

How long is data retained?

Transaction data is retained according to regulatory requirements and our data retention policy. Personal data can be deleted upon request (subject to legal requirements).

Where is data stored?

Data is stored in secure data centers in the region where your Omise account is registered, with appropriate redundancy and disaster recovery measures.

Related Resources

• Authentication - API key security
• Security Best Practices - Implementation guidelines
• Fraud Protection - Fraud prevention
• 3D Secure - Card authentication
• Webhooks Security - Webhook verification

---

Questions about security? Contact security@omise.co or reach out to your account manager.