Caribbean payments
Why Stripe cannot serve a Trinidad-registered company, and what to use instead
Stripe onboards a legal entity, and eligibility follows where that entity is registered and banked. A Trinidad-registered company with a US dollar account abroad is still not eligible. Here is what that means and what works.
The single most common surprise in a Caribbean product build is discovering, late, that the payment provider everyone assumed would work does not. Stripe is the usual case. It is worth being precise about why, because the reason determines what to do about it.
Eligibility follows the entity
Stripe onboards a legal entity. Eligibility follows where that entity is registered and banked, not where the customer's card was issued and not what currency is charged. Trinidad and Tobago is not a supported country. A Trinidad-registered company holding a US dollar account abroad is still a Trinidad-registered company, and is still not eligible.
Becoming eligible means standing up a company in a supported jurisdiction. That is a real option, and the firm's own research points at what it involves: a US LLC rather than a corporation, because the US–Trinidad treaty does not reduce US withholding tax on dividends, or a UK limited company, which may serve better than either. It is a corporate decision with tax, banking and filing consequences. It is not a prerequisite for taking payment.
What works from Trinidad and Tobago
- Republic Bank EPay: TTD card acquiring, with the same product across Republic's OECS footprint.
- PowerTranz, formerly First Atlantic Commerce: the gateway behind most Caribbean bank acquiring, with support for recurring payments and tokenisation.
- Bank transfer against an issued invoice: the realistic rail for a substantial programme, reconciled by an administrator against a bank reference.
Both acquirers can process a USD transaction. Whether either can settle USD to an account held abroad is a question to put to them directly, and a yes is far cheaper than incorporating abroad.
Build for the constraint
The design consequence is simple: the payments layer is an interface with pluggable adapters, selected by configuration. Order, invoice, ledger, receipt, refund and reconciliation logic is shared and provider-agnostic. Adding a rail later means implementing one interface and passing one shared contract test suite. If a foreign entity is ever created and Stripe becomes available, it is one more adapter rather than a rebuild.