Fraud Protection

Omise is committed to protecting all partners against fraud with security best practices that detect, analyze, and prevent suspicious transactions. Every card processed through Omise's system passes through multiple security measures that work in conjunction, including pre-authorization (see Fraud monitoring and control), tokenization, IP geolocation, and behavior analysis.

🌍 IP geolocation

Omise's IP geolocation technology identifies the geographic location of a device from which an online order is placed. It attempts to determine the real-world location from the country level down to the city area, and compares that location data with the card's own data to assess fraud risk.

🚦 IP reputation blocks and dynamic IPs

This is a different mechanism from the IP geolocation fraud-scoring described above. Charges can occasionally fail with a 403 Forbidden error if the request originates from an IP address flagged by a reputation-based security rule. Rules like this typically rely on threat-intelligence data maintained by third-party providers, rather than a list Omise curates itself — so an IP can be flagged and blocked without any Omise-specific action being taken against that merchant.

This can happen even to legitimate merchants using well-known cloud providers, because attackers also use cloud infrastructure to launch attacks. If a merchant's server is assigned a dynamic IP address, the specific IP it receives can occasionally be one that was previously used by a bad actor and hasn't yet been cleared from a reputation list, even though the merchant did nothing wrong.

The threat-intelligence data behind these rules is typically maintained by third parties — for example, cloud and CDN providers publish managed rule groups that flag IPs associated with known malicious activity — rather than curated by Omise directly. An IP can be removed from these lists over time once the data maintainer determines it's no longer associated with malicious activity. You can check whether a given IP address has any publicly reported history using third-party tools such as AbuseIPDB.

This is distinct from rate limiting — a merchant can hit this kind of block regardless of transaction volume, even with a very small number of daily charges.

🧠 Behavior analysis

Omise adds another layer of protection through the real-time identification of fraudulent transactions. Omise deploys machine learning models that use behavioral analytics to monitor transactions, detect anomalous activity, and proactively identify hidden fraud patterns — stopping fraudulent charges before they occur.

🎫 Tokenization

Tokenization safely stores and exchanges sensitive credit card data from one party to another, in the form of a randomly generated value created for one-time use. Every card processed with Omise goes through tokenization.

Here's how it works:

1. The User Browser sends the card data directly to the Omise Server. This step bypasses the Merchant Server entirely — the merchant's own server never receives or touches the raw card data.
2. The Omise Server responds directly back to the User Browser with a Token, again without routing through the Merchant Server.
3. The User Browser forwards the Token, along with the order details, to the Merchant Server. The Merchant Server then forwards that same Token, along with the charge request, to the Omise Server.

Because the token — not the raw card number — is what reaches the merchant's server, the merchant never has to store or secure sensitive card data directly.

How tokenization benefits merchants

Whether running one-time checkouts or processing recurring payments, tokenization reduces your business's liability by allowing you to not worry about securing sensitive data, while retaining essential card information without compromising its security.

How tokenization benefits cardholders

As credentials are never disclosed, cardholders can rest assured that even if their mobile device were lost or stolen, or if there was a breach, only the tokens would be compromised. Unless the cardholder gives consent, these tokens are generated for one-time use and are valid for one particular merchant only.

🔐 3-D Secure

3-D Secure (3DS) adds another level of protection to merchants and cardholders. With the service enabled, the chances of fraud are reduced significantly, as each transaction requires a second authentication factor provided by the card issuing bank (an OTP or SMS token).

From the cardholder's perspective, this is what a 3-D Secure purchase looks like:

1. Checkout form (merchant site) — the cardholder fills out and submits the checkout form on the merchant's own website.
2. Authentication (card issuer site) — the cardholder is redirected away from the merchant's site to a page hosted by their card issuing bank, where they enter their OTP or SMS token to authenticate.
3. Transaction complete (merchant site) — once authentication succeeds, the cardholder is redirected back to the merchant's site, where the transaction is confirmed complete.

Business types that benefit from 3-D Secure

• Flight tickets
• Mobile top-up
• Game money, digital money, prepaid cards
• Digital goods such as music, movies, and software
• Any online content where fraud and chargebacks occur frequently

When to consider enabling 3-D Secure

• Your business has lost many chargebacks and is unable to provide proof of delivery.
• You've experienced many cases of fraud.
• Your business does not require recurring payment and would like more protection against fraud.

The only disadvantage of enabling 3-D Secure is that cardholders will be redirected to a bank page for every purchase. Because of this, merchants will not be able to process fully automatic/recurring payments. However, the Customers API can be used so that cardholders do not have to re-enter their card details every time — all they have to do is authenticate with 3-D Secure whenever a payment is made.

The technical flow behind 3-D Secure

1. The User Browser sends the Token and Order details to the Merchant Server.
2. The Merchant Server sends the Charge and Token to the Omise Server, along with a return_uri — the URL Omise should send the cardholder back to once authentication is complete.
3. The Omise Server responds to the Merchant Server with an authorize_uri — the URL where the cardholder needs to go to authenticate.
4. The Merchant Server redirects the User Browser to that authorize_uri. This is what lands the cardholder on the card issuer's authentication page.
5. Once authentication succeeds, the browser is redirected back to the original return_uri, sending the cardholder back to the merchant's own site.
6. The Merchant Server confirms the transaction, and the cardholder sees the Transaction Complete confirmation.

Learn more on how to implement 3-D Secure.

🎭 Friendly fraud

Friendly fraud, also known as chargeback fraud, occurs when the cardholder takes advantage of the chargeback process to secure a refund. Generally, the customer makes an online purchase, and once the goods or service has been delivered, they deliberately request a chargeback from the issuing bank instead of contacting the merchant for a refund.

Why friendly fraud occurs

• Intention to get something free
• Cardholder experiencing buyer's remorse
• Someone else in the family made the purchase, and the cardholder did not want to honor the charge in the first place
• The cardholder didn't recognize or forgot about the purchase
• The cardholder is not qualified for a standard refund (for example, the cardholder may have exceeded the refund limit)

Although multiple tools combine efforts to determine a transaction's legitimacy and help minimize fraud losses, technology is not everything. People have a considerable contribution to make in preventing fraud. Omise's fraud team is trained extensively to spot the first signs of attacks. Merchants are also encouraged to report any charge believed to be fraudulent, so Omise can use that information to help improve the system.

❓ FAQ

Why did my charge fail with a 403 Forbidden error even though nothing changed on my end? This can happen if your server's IP address was flagged by a reputation-based security rule — these rules typically rely on threat-intelligence data maintained by third parties rather than a list Omise curates itself, and are most likely to affect dynamic (rotating) cloud server IPs. See IP reputation blocks and dynamic IPs above; switching to a fixed IP is usually the reliable fix.

Is 3-D Secure mandatory for all merchants? No. It's required only for certain business types; Omise's fraud analysts determine whether it's necessary for your account based on your business's risk profile.

Can I still process recurring payments with 3-D Secure enabled? Not fully automatically — cardholders are redirected to authenticate on every purchase. However, the Customers API lets you save card details so cardholders don't need to re-enter them each time; they still need to complete 3-D Secure authentication for each payment.

What does it mean if a charge shows as blocked by the fraud system? It means the charge was blocked before completion; the status is marked failed_fraud_check on the dashboard.

What's the difference between friendly fraud and other fraud? Friendly fraud is when a legitimate cardholder who did approve the purchase later disputes it anyway to get a refund without returning the goods — as opposed to fraud where the cardholder never approved the charge at all.

Are tokens ever reusable? A token itself is generated for one-time use. With the cardholder's consent, their card can instead be saved to a customer record for future charges — that reuses the saved card, not the original token itself.

👉 Next steps

• Security Overview
• How to implement 3-D Secure?