TrustBarrier
Now onboarding merchants

Catch fraud on
attempt #2,
not attempt #15.

A pre-charge screening API for Caribbean merchants. One HTTPS call before you charge the card returns block or allow in under fifty milliseconds. When one merchant reports a chargeback, every connected merchant inherits the protection.

p95 server-side decision
< 50 ms
Uptime target
99.9%
Out of PCI scope
by design
SDK behaviour on outage
Fail-open
Integration

Five lines and a Bearer token.

Two required fields. One response field. No SDK, no webhook receiver, no PCI scope expansion. The contract has been deliberately kept this small so you can ship in an afternoon and never come back to maintain it.

Optional fields enrich the score and the network signal — email, phone, card_fingerprint, delivery_lat/lng. Send what you have; we match against what's there.

checkout.php
// Before charging the card:
$response = $http->post('https://api.trustbarrier.tech/v1/check', [
    'headers' => ['Authorization' => "Bearer {$TB_KEY}"],
    'json' => [
        'ip'      => $customer->ip,
        'address' => 'LG Smith Blvd 101',
    ],
    'timeout' => 2,
]);
200 OK · application/json 28 ms
{
  "decision":     "allow",
  "reason_codes": [],
  "score":        0,
  "event_id":     "ev_01HF8KZX9PMQ4YRTBN3W7K2A6V"
}

Read decision. If "block", decline the order. Otherwise, charge as you would today.

Product

A screening layer purpose-built for the markets you actually serve.

Generic global vendors price for Fortune 500 transaction volume and miss the patterns specific to small-island commerce. TrustBarrier was designed from day one for markets where addresses are free-form, telecom carriers are concentrated, and the same fraud actors hit every merchant in turn.

Telecom-aware decisioning

Carrier-grade NAT means a single IP can mask tens of thousands of legitimate customers. The engine carries a curated registry of protected ISP ranges, so you never lock out a real buyer because of how their carrier routes traffic.

Cross-merchant intelligence

A chargeback at one merchant becomes a signal at every other. Reported signatures — IP, address, card fingerprint, email, phone — propagate through a curated global pool within minutes, with merchant-controlled opt-in.

Drop-in, no rewrite

The contract is two required fields and one response field. There is no SDK to vendor, no event bus to wire up, and no PCI scope to revisit. If your checkout already does an HTTPS call, you can ship TrustBarrier today.

Architecture

Sits in front of your processor. Stays out of your card data.

TrustBarrier is a pre-authorisation screening layer. It does not replace 3DS, it does not replace your gateway, and it does not see PAN, CVV, or track data. The integration touches one path in your checkout — the moment between order capture and the call to your processor.

Fail-open by design
If the API is unreachable within your timeout, your SDK proceeds to the processor as normal. An outage will never cost you a sale.
Out of PCI scope
Send IP, delivery address, and an optional masked card fingerprint (BIN + last four + expiration). None of that is regulated under PCI DSS.
Auditable from day one
Every decision and every blocklist mutation is captured in an immutable audit log with five-year retention.
Request lifecycle
1
Customer submits order
Your checkout captures IP, delivery address, optional identifiers.
2
Your server calls /v1/check
Bearer auth. JSON body. 2-second timeout recommended.
3
Decision returns
block · allow · reason codes · score · event ID.
4
You proceed or decline
On block: decline politely. On allow: charge as normal.
5
Chargeback later? POST /v1/report
The signature is on your blocklist immediately. Optional: share with the network.
Decision engine

Fourteen signals. One score. Tunable per merchant.

Hard rules block on definitive matches — known bad IP, address, email, phone, or card fingerprint. Everything else feeds a score from a fifty-point baseline. Cross your threshold and the decision flips to block; stay below it and the response is allow with the contributing signals attached for your audit log.

Network effect

Negative-history reuse

Every block decision on any merchant on the network feeds back into the score for the next thirty days. The first merchant pays the cost; everyone else inherits the protection automatically. No reports, no exports, no manual sharing.

Network effect

IP reputation across the network

A request IP that has been blocked by three or more merchants in the last twenty-four hours is treated as compromised infrastructure, not a customer. Catches the IP rotation that single-merchant velocity rules miss.

Network effect

Cross-merchant blocklist signals

Any identifier — card, email, or phone — sitting on another merchant's local blocklist contributes weight even before a chargeback is filed. The network is loud well in advance of any individual merchant's first loss.

Evasion resistance

Email canonicalisation

The classic gmail dot-and-plus trick — john.doe+x@gmail.com versus johndoe@gmail.com — collapses to one inbox in the matcher. Outlook, iCloud, Proton, FastMail, and Yahoo aliases are handled per their documented rules.

Evasion resistance

Address fuzzy match

A small character-edit on a blocklisted address — a missing letter, a transposed digit — still triggers a soft signal. Exact matches stay on the hard-rule path; near-misses lift the score without false-positiving the neighbour next door.

Evasion resistance

Disposable-email detection

A curated registry of roughly five hundred throwaway-mail providers, refreshed against the public lists and tunable per merchant. Mailinator, Guerrilla, ten-minute mail, and the long tail of self-hosted clones all surface as a soft signal, never an automatic block.

Behavioural patterns

Velocity & burst detection

Sliding-window counters on the same IP, card fingerprint, or email address. Eleven attempts from the same IP in five minutes, or six different cards on the same email in an hour, are flagged before the decline rate has a chance to climb.

Behavioural patterns

Device-fingerprint identity drift

A single browser fingerprint paired with two or more distinct emails or cards on the same merchant inside thirty days is the canonical sock-puppet pattern. The signal scales with the number of fresh identities tied to that one machine.

Card intelligence

Card fingerprint matching

PCI-clean: brand, BIN, last four, and expiration — exactly the fields your processor already exposes. A reissued card with a fresh expiration is a separate signature, not a stale block. The engine never blanket-blocks on BIN alone — that would lock out an entire issuing bank.

Every fired signal is returned in the API response and captured in the immutable audit log. You see exactly which weights moved the score, with no black-box scoring decisions you cannot defend in a chargeback dispute.

FAQ

Common questions

Does TrustBarrier replace 3DS or our gateway?
No. The screening layer runs before your gateway. 3DS continues to operate at the processor. TrustBarrier complements both rather than replacing them.
How does this affect our PCI posture?
It does not. TrustBarrier never sees PAN, CVV, or track data. The only card-related field accepted is the masked fingerprint your processor already exposes — brand, BIN, last four, expiration — and none of that is regulated under PCI DSS.
What happens during a TrustBarrier outage?
The recommended SDK pattern fails open: if the API does not respond within your timeout, your checkout proceeds to the processor as it would today. We will never cause a missed sale.
How does the cross-merchant network work?
Reporting is opt-in per chargeback. Once submitted, the signature passes a reputation review and becomes available to the rest of the network. Beyond explicit reports, every blocked decision automatically lifts the risk score on the same identifier across every other merchant for the next thirty days — no manual sharing required.
Do you support our platform — WordPress, Shopify, AeroCMS, Lightspeed?
Native plugins are on the roadmap. Until then, integration is an HTTPS call from your server. Reference implementations for the most common platforms are available on request.
Where is the data hosted?
Currently in the EU under GDPR-equivalent protections, behind a Cloudflare-fronted edge. On-island hosting for enterprise contracts is available on request.

Stop the next chargeback before it happens.

The first cohort of merchants is being onboarded now. A short call, an account, an integration guide — and screening starts.