Policy
Editorial and corrections policy
How the material here is sourced and checked, what happens when it is wrong, and what is done to stop it going stale.
Sourcing
Technical claims come from two places: the provider's public documentation, and test integrations built independently against their sandbox. Where those two disagree — and they often do — the behaviour observed in the sandbox is what gets published, with the discrepancy noted.
Regulatory claims cite the instrument itself. If a piece refers to what SAMA, the CBUAE or the EBA requires, the link goes to their publication, not to a law firm's summary of it.
Pricing figures are dated at the point of publication and attributed to the provider's own published schedule. Providers change these pages without notice, so treat any figure older than a few months as indicative.
Independence
No provider, bank or regulator sees an article before publication. None has any right of review, approval or veto, and none is offered one.
Advertising is served automatically by Google and sold by Google. I have no relationship with the advertisers whose ads appear and no ability to influence which ones do. Advertising has never been raised in connection with any editorial decision, and if a provider ever made coverage a condition of anything, that fact would be published.
I am employed as a developer in financial technology. Nothing published here draws on my employer's internal systems, client relationships, incident history or commercial terms. Where my employer's own products would be relevant to a comparison, they are left out entirely rather than covered at a distance.
Corrections
Errors get fixed rather than quietly deleted. The process is:
- Report it to hello@paymentsatlas.com with the page URL and what is wrong. You do not need to prove it; a pointer is enough.
- Substantive errors are corrected within three working days where possible.
- A correction that changes the meaning of a passage is marked on the page, with the date and a note of what changed. Typographical fixes are made silently.
- An article that turns out to be wrong in its central claim is retracted rather than edited into shape, and the retraction stays at the URL.
Keeping guides current
Payment APIs change and regulations move. Every article carries its publication date, and articles revised after publication carry an updated date as well.
Guides are reviewed when a provider announces a breaking change, when a reader reports that sample code no longer runs, or roughly annually, whichever comes first. Where a guide is known to be out of date and has not yet been rewritten, it is marked as such at the top rather than left to look current.
Verification
Whatever tools are used to research or draft a piece, nothing is published on the strength of a secondary summary. Technical claims are run locally; regulatory claims are traced to the instrument itself. An unverified claim about how a payment API behaves, or about what a regulator requires, is worse than no claim at all.
Reader contributions
Unsolicited guest posts, sponsored articles and link-insertion requests are declined and are not answered individually. Corrections, technical questions and suggestions for what to cover next are always welcome.