ReachPay in Saudi Arabia: implementation and integration, assessed on the evidence. ReachPay is a Reachware product and we build, implement and support it — what follows is what we would tell you in the room.
ReachPay is part of the Reachware suite, alongside Connect, Studio, Fatoora and the rest; Reachware describes Reach Pay as unifying online and offline payments into one platform for monitoring and optimization. That single sentence is the whole fit question: if your payments are already unified and visible, ReachPay solves a problem you do not have.
You take money through more than one channel — a till, a website, an app, an invoice — and nobody in finance can tell you, before month end, what was taken where. You are already using other Reachware components, so the integration surface is shorter than it would be with a standalone product. And your payment providers are staying put: ReachPay is a layer over your acquiring arrangements, not a replacement for them.
We do not recommend ReachPay when you take payment through one channel and one provider — the unification layer has nothing to unify, and you are buying reporting you could get from the provider's own portal. We also advise against it when the real problem is reconciliation inside your ERP rather than visibility across channels; that is an accounting integration project, and a payments platform will not fix it. In both cases the honest next step is a fit assessment of where the money actually goes missing, not a licence.
We state only what Reachware publishes: ReachPay unifies online and offline payments into one platform so they can be monitored and optimized, and it sits inside an integration and automation suite built around Reachware's iPaaS. Everything past that — which acquirers, which wallets, which card schemes, which reconciliation formats — is configuration, and configuration claims belong in a written scope from the vendor, not on our page.
Three, in the order they bite. First, a unification layer inherits every quirk of every channel it unifies; the work is in the connectors, not the dashboard. Second, it does not change your commercial terms — rates, settlement timing and chargeback handling stay with your providers. Third, and this is the one that surprises boards: we make no statement about any party's regulatory licensing or authorisation, because none is first-party evidenced. Ask the provider for its own position in writing and have your compliance function read it.
Two published obligations shape every Saudi payments project. VAT is charged at 15%, so every channel has to produce a compliant tax document, not just a receipt. And the Zakat, Tax and Customs Authority's E-Invoicing (Fatoorah) programme has been in force in two phases — Phase 1 from 4 December 2021 and Phase 2 from 1 January 2023 — which means an invoice generated at the point of payment has to reach your e-invoicing solution in a form it can clear. A payments layer that unifies channels but drops out of the e-invoicing chain creates a second reconciliation problem in place of the first. That chain is what we test first. See the wider payments and e-invoicing category for how the pieces fit, and retail for how it plays out in a multi-channel estate.
We publish no price, because Reachware publishes none and a number we invented would be worse than silence. The cost model we build with you has four lines: the licence or subscription as quoted to you; the connector work, which is the line that moves most and scales with the number of channels and the state of their APIs; the finance-side work to make the output reconcile inside your ERP; and the running cost of owning a connector estate that breaks whenever a provider changes an interface. The fourth line is the one most proposals omit.
The honest shortlist depends on where your payments already live. If you run one of the major ERPs, its own payments module may make a separate layer redundant. If you run a modern POS estate, the POS vendor's reporting may already unify the channels you care about. If you are deep in the Reachware suite, ReachPay is the short-integration option and that matters more than a feature grid. We score those routes against your actual channel map, and publish the method, not a ranking — our software comparisons show the shape of that work.
We start by mapping every way money enters the business and every system that has to know about it. That map, not a demo, decides whether ReachPay is the answer. That map is yours regardless of what you then buy, and it is the artefact that makes any later comparison possible.
The integration list is short to write and long to build: acquirers and payment providers, the point-of-sale estate, the e-commerce front end, the ERP or accounting ledger, and the e-invoicing path. We sequence them by risk, prove the ledger-facing ones first, and keep the old reporting running in parallel until the new figures agree.
Finance and treasury need to trust the new numbers before they stop producing the old ones, so training is built around the month-end close, not the dashboard tour. Branch and channel staff get the exception handling — refunds, failures, mismatches — because that is where a payments cutover is actually felt. The first close after go-live runs with us on call.
We publish no counters here. The measurable outcome of a payments project is agreed with you before it starts — typically the time to close the month and the value sitting unreconciled at the end of it — and it is measured against your own baseline. A percentage lifted from someone else's project tells you nothing about yours.
The variable is the connector count, not the platform. We size it after the channel map exists, and we put the estimate in writing with the assumptions it rests on — an estimate given before the map is a sales artifact.
Licence plus connector build plus finance-side integration plus the running cost of maintaining connectors against provider API changes. We model all four with your figures. We do not publish a benchmark, because payment estates are not comparable enough for one to mean anything.
Compliance is a property of your deployment, not of a product name, and we make no regulatory claim on Reachware's behalf. What we do is concrete: we check that the transaction records reach your e-invoicing solution in a form it can clear against ZATCA's published requirements, we establish where the data is hosted, and we get the vendor's own statements in writing for your compliance function to assess.
Whatever your existing ERP, POS and provider portals already offer, first — because the cheapest payments platform is often the one you have already paid for. The alternative set is written into the assessment report, with the reason each was kept or dropped.
That is its stated purpose: it unifies channels rather than replacing the providers behind them. Whether it integrates with your systems is an evidence question, and the evidence is a connector inventory and a written vendor confirmation per interface, which we collect during the assessment.
Because ReachPay is a Reachware product and we build, implement and support it, so this is the position of the team that would do the work, not an arm's-length comparison. We cannot offer you neutrality between vendors on this page. What we can offer, and do, is the channel map before the recommendation, and the same team that would advise "buy" saying "you do not need this" in writing when the map says so — the section above on when we don't recommend it is on this page for that reason.
We name organizations only with their consent and in direct conversation, never on a product page. Ask us for references in your sector and we will arrange the calls.
No composite case study appears here. Relevant work is walked through attributably in a first conversation — the standard we suggest you hold every bidder to, including us.
We publish no testimonial quotes on this page. Speak to our references directly; it is worth more than a curated pull-quote.
Accreditations and partnerships are listed in proposals, where they are current and checkable. The material fact for this page is stated plainly instead: ReachPay is a Reachware product and we build, implement and support it, so this is the position of the team that would do the work, not an arm's-length comparison. What qualifies the advice is method: a documented channel map and a written scope.
Continue with the payments and e-invoicing category, our software comparisons, the retail sector page, or a fit assessment.
A word about "neutral", because we would rather say it than have you wonder: we build and support this platform, so we cannot offer you neutrality between vendors on this page. What we can offer, and do, is neutrality about whether you need a unification layer at all — the section above on when we don't recommend it is on this page for that reason. Bring us your channel map, or let us build one. You will leave with a written position on whether ReachPay belongs in your estate and what it would cost to put it there. Request a demo or book a fit assessment.
Unlimited support included.
One-on-one onboarding sessions.
Training videos, webinars, & demos.