How should a multi-currency transaction be stored?

As both amounts and the rate between them, never as one amount plus a conversion done when somebody looks. A charge presented to a customer in pesos and settled in dollars has two true figures and a rate that applied at a particular moment. Store the presentment amount with its currency, the settlement amount with its currency, the rate, and when the rate was taken. Converting on read produces a different answer every time the rate moves, which means a statement that changes after it was sent.

Our reconciliation is out by small amounts on international payments.

Usually fees and the rate, in that order. The amount a provider settles is the charge minus a fee that may itself be in another currency, converted at a rate that is not the one quoted to the customer. If the system records only the gross figure, the difference has nowhere to live and reconciliation absorbs it as a mystery. Recording gross, fee, net and rate as separate stored values makes the arithmetic explicit, and the differences stop being mysterious.

What does a screening requirement do to the payment flow?

It adds a state most payment code does not have. A payment is not only approved or declined - it can be held pending review, sometimes for days, and the customer has to be told something true in the meantime. That means the order state machine needs a held state with a reason and a reviewer, the funds position has to reflect money that is neither captured nor released, and nothing downstream should treat a held payment as a failure and retry it.

Can one system serve customers in several Latin American countries?

Usually yes, and the things that actually vary are smaller than people expect - tax identifiers, address formats, phone validation and the payment methods offered. Those belong in configuration per country rather than in forked code. What does not generalise is tax treatment and invoicing, which is worth checking per country before promising a single flow.

Laravel in Miami

Laravel development for Miami cross-border payments and trade

A Laravel development company for Miami trade, finance and consumer businesses. A charge in one currency settled in another, a rate that has to be recorded, and screening before money moves.

Updated November 4, 2026

Miami's businesses move money across borders, and that turns a payment from one number into three.

A customer in Bogotá is quoted a price in pesos. The business settles in dollars. A provider takes a fee somewhere in between, possibly in a third currency, at a rate nobody quoted. Every one of those figures is true, and a system with a single amount column can only hold one of them - which is how reconciliation in cross-border businesses becomes a monthly argument.

Two currencies and a rate, all stored in Laravel

The decision that prevents most of the later pain is to treat the rate as part of the record rather than as a display concern.

A transaction stores the amount presented to the customer with its currency, the amount settled with its currency, the rate applied, and the moment the rate was taken. All four are facts about what happened. Converting on read instead - taking the dollar figure and applying today's rate to show pesos - produces a statement that changes between viewings, which is indefensible when the customer has a screenshot of the first version.

The same reasoning extends to fees. A provider settles the gross amount minus a fee, and the fee may be charged in another currency at another rate. Gross, fee, net and rate as four stored values make the arithmetic explicit. One net figure makes every small discrepancy permanently unexplainable. Money and dates are the decisions you cannot undo covers the integer-cents half, which matters more when two currencies and three roundings are involved.

A held Miami payment is not a payment that failed

Cross-border money movement brings screening, and screening introduces a state that most payment code does not model.

A payment can be approved, declined, or held for review - and a hold can last days. The application has to represent that honestly: the order is in a held state with a reason and an owner, the customer is told something true rather than shown an error, and the money is neither captured nor released.

The failure mode to avoid is treating a hold as a failure. Retry logic that re-submits a held payment creates duplicates that somebody has to unwind, and a customer-facing error on a payment that is actually under review produces a support conversation nobody can answer. Being safe to run twice matters, and so does having a state that means "waiting on a human".

What actually varies by country from Miami

Miami businesses selling across the Americas usually ask whether they need a system per market. Generally not, and the differences are narrower than they look.

Tax identifier formats vary and are worth validating properly rather than accepting as free text, because a wrong identifier surfaces as a rejected invoice later. Address formats and phone validation vary. The payment methods on offer vary considerably, and that is configuration rather than code.

What does not generalise is tax treatment and invoicing requirements, and those are worth confirming per country before promising a single flow. Everything else is one system with a table of country settings, which is far cheaper to maintain than five deployments that have drifted apart.

A Miami payout needs a beneficiary that was validated before the money moved

Taking money and sending money are not mirror images. A failed collection is an inconvenience; a payout to a wrong account is a recovery process involving two banks and a lawyer.

So the beneficiary is a record with a lifecycle of its own, not a set of fields on a transfer. It is created, validated against whatever the destination rail supports - an IBAN check digit, a routing number lookup, a name match where the rail offers one - and only then usable. A change to the account number resets that state, because a verified beneficiary whose details were edited is no longer verified, and the most common fraud in this area is exactly that edit.

Returns have to be modelled, because they happen days later. Funds come back with a reason code, and the original payout is neither successful nor simply failed - it completed, then reversed, and the customer's balance has to reflect both movements rather than being quietly set back. Re-presentment after correcting the details is a new attempt linked to the old one, so the history reads as what happened.

Cut-offs are the operational edge. A rail closes at a local time in a local zone and settles on business days in a calendar that is not the customer's. A payout submitted at four in the afternoon in Miami may be tomorrow's payment or Monday's, and telling the customer which, before they ask, is cheap once the calendar is data rather than an assumption.

Laravel screening as a pipeline stage that can stop a Miami transfer

Sanctions and watchlist screening is not a validation rule. It is a stage that can hold a transaction indefinitely, and the application has to be built to hold things.

A held transfer is a state, not an error. The money has not moved, the customer has been told something truthful about why, and a reviewer has a queue. Systems that model screening as a boolean check either block legitimate payments with no route to resolution or pass everything and record nothing.

False positives are the normal case, which surprises people. Common names match list entries constantly, so the review queue is load-bearing rather than exceptional, and its throughput determines whether the product works. A reviewer needs the matched entry, the fields that matched, the score and the customer's history in one place, and their decision - cleared, or escalated - is stored with a reason against that transaction.

What is screened has to be re-screenable. Lists are republished, and an entry added today can match a counterparty that was cleared last month. That means the screening result stores which list version produced it, and a list update triggers a re-run against open relationships rather than only against new transactions. It is the same versioned-reference-data pattern that runs through every part of this work, and here the consequence of skipping it is regulatory rather than merely annoying.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - state privacy laws, sales tax, invoicing - is on the United States market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption and no US entity on our side.