5 min read
Finality is a feature. So is payment protection.
Protection does not undo finality. It gives a chosen payment a short window before it becomes final, then settles it like any other. Why the two belong together.
Finality is one of the most valuable properties a payment system can have. When a payment is final, the recipient can rely on it. It cannot be pulled back weeks later, the money is not provisional, and nobody in the middle can quietly change the result. Blockchains deliver this more cleanly than most systems ever have.
So it is worth being precise about what payment protection changes. It does not weaken finality. It changes when a chosen payment becomes final.
What payment finality actually gives you
Finality is easy to undervalue until it is missing. A merchant who receives a final payment can ship immediately without wondering whether the money will disappear. A freelancer can spend what they were paid. A business can close its books without carrying a reserve against payments that might still be reversed.
Systems with provisional settlement pay for their flexibility in uncertainty. A payment that can be challenged for weeks is, for that whole time, not quite money yet. That uncertainty has real costs, and it is often borne by the people least able to absorb it.
Crypto removed that uncertainty. The question is whether it also has to remove every way of dealing with a payment that goes wrong.
The problem is timing
With an ordinary crypto transfer, a payment becomes final at the moment it is sent. That is ideal when both sides already trust each other, or when the thing being paid for has already been delivered. It is less ideal when payment comes first and delivery comes later, which describes a large share of everyday commerce.
In those payments, the useful information arrives after the money moves: whether the package came, whether the work was done, whether the invoice was genuine. Finality at the moment of sending leaves no room for that information to matter.
Moving the moment, not removing it
A protected payment settles conditionally. When the payer sends it, it enters a protection window rather than landing in the recipient’s wallet. During the window, three things can happen, and each one ends in final settlement.
- The payer releases it early, and it settles to the recipient.
- The window closes with no dispute, and it settles to the recipient.
- The payer opens a dispute before the window closes, and a designated arbiter settles it to either the original payer or the original recipient.
In every case the payment ends somewhere definite, and from that point it is final in exactly the way any other transaction is. Nothing about the underlying chain changes. What changes is that a payment the payer chose to protect does not settle until the window has done its job.
Is this a chargeback for crypto?
It shares the familiar idea, a way to raise a problem with a payment, but it works the other way round. A card chargeback reverses a payment that has already settled, often weeks later. A protected payment never settles until its window has passed or a dispute has been decided, so nothing has to be reversed.
That difference matters for the recipient. With a chargeback, money that looked final can be taken back. With a protected payment, the recipient knows from the start that the payment is protected, for how long, and that once it settles it stays settled. Protected Pay is not a card network or chargeback system, and it does not carry the legal protections those come with; what it offers is a short, rule-bound window before final settlement.
A choice per payment
Protection is opt-in and per payment. The payer decides which payments to protect and for how long, from an hour to thirty days. Ordinary transfers stay exactly as they are. That matters, because finality at the moment of sending is the right answer for many payments, and nobody should have to give it up to gain protection on the few that need it.
The window can be matched to the payment. An hour or a day suits digital goods and quick handovers. A week or two suits shipped goods. Thirty days suits services and work delivered over time. A payer who is satisfied early can release the payment at once, so the recipient is not kept waiting longer than the deal requires.
Rules instead of discretion
The value of finality comes from predictability, so a protection layer has to be predictable too. In the protocol behind protected payments, the terms of each payment are fixed when it is created: who sent it, who receives it, the amount, the arbiter, and when the window closes. None of them can be changed afterwards.
Funds in a protected payment can only ever go to the original payer or the original recipient.
The arbiter cannot redirect a payment, cannot receive it, and can only act on payments that were actually disputed. An undisputed payment settles to the recipient when its window closes, and anyone can trigger that final step. The outcome depends on rules both parties can read in advance, not on anyone’s later judgment beyond the one decision a dispute asks for.
Even that decision is narrow. The designated arbiter chooses between a full release and a full refund. There is no partial outcome to negotiate and no third destination, and either side can end the dispute early in the other’s favour. Predictable rules are what let a recipient accept a protected payment with the same confidence they would accept a final one.
Both, not either
It is tempting to frame this as a choice between finality and protection. It is not. Card networks and banks bundle protection with provisional settlement and long periods of uncertainty. Crypto offers certainty with no way to resolve a problem. Protected payments aim for the useful middle: a short, chosen, rule-bound window, then the same finality crypto has always offered.
Common questions
Does protection make crypto payments reversible?
No. Settled payments stay settled. Protection changes when a chosen payment settles, and the outcome of a dispute is decided before settlement, not after it.
Who decides a dispute?
The designated arbiter named when the payment was created. It can release the full amount to the recipient or refund the full amount to the payer, and nothing else.
Why would a recipient accept a protected payment?
Because it makes buyers more willing to pay, and the rules are fixed in advance: the money is held for that one payment, it cannot go anywhere but to the recipient or back to the payer, and an undisputed payment settles to the recipient when the window closes.
The model is being reviewed and hardened for real money. The principle will not change: finality is a feature, and so is being able to resolve a problem before a payment becomes final.