An integration map
A diagram of every system involved, what data moves between them, in which direction, and which system is the source of truth for each field.
Web apps
Stop typing the same order into two systems
Your store, your gateway, your courier account and your accounting system each hold a slightly different version of the same order. Connecting them is mostly a question of deciding which one is right when they disagree, and then making that stick.
Who this is for
For companies running two or more systems that each work fine on their own and disagree with each other. If what you actually want is one of those systems replaced, that is a build project with a different shape and a different budget.
What you get
What we deliver
The connection itself
The working link between the systems, built against their documented APIs, with credentials held server side, never anywhere a browser can reach.
A sync that survives a bad afternoon
Queuing, retries and idempotency, so a courier API being down for an hour delays an order instead of losing or duplicating it.
Failures a person actually sees
Failed jobs report to email or chat with the record and the reason, instead of accumulating quietly in a log nobody opens.
A reconciliation view
One screen showing what matched, what did not and what is still waiting, so finance chases a named difference rather than a hunch.
Handover documentation
Endpoints, field mappings, rate limits and what to do when a vendor changes their API, written so someone who is not us can pick it up.
Why cash on delivery changes the wiring
Cash on delivery is still a normal way to pay for an online order here, and it changes the shape of the integration. Payment is not confirmed by a gateway webhook arriving seconds after checkout, it is confirmed days later by a courier remittance file, often a spreadsheet with the courier's own reference numbers rather than yours. Everything downstream, stock, accounting, commission, has to wait for that file and match against it, and matching is where most of the work sits. The rest of the job is usually local pieces that overseas integration work never touches: PayMongo, Maya or DragonPay on the payment side, a courier account for booking and tracking, and a Lazada or Shopee listing that has to stop selling stock the website already sold an hour ago.
Questions
What people ask before they buy this
What if the system we need to connect has no API?
That happens more often than vendors admit. There are usually other routes: a scheduled file export, a read-only copy of the database, or a webhook the vendor will switch on if asked. We look for those first. If none of them exist, connecting that system becomes a question of replacing it, and that is worth knowing before you budget for a link that cannot be built.
Can you connect our checkout to a local payment gateway?
Yes, normally through PayMongo, Maya or DragonPay rather than to the wallets directly, because that is how those payment methods reach a merchant. The interesting part is not the checkout, it is the webhook: what happens when it fires twice, arrives out of order, or does not arrive at all. We build the reconciliation so a missing webhook shows up as an unmatched payment rather than as an order nobody ever shipped.
Which system wins when the two disagree about a value?
We decide that in writing, field by field, before any code is written. It is the least interesting part of the project and reliably the part that causes arguments later. Where both sides can legitimately change a value, we set a rule for which one wins, and we keep a record of what was overwritten so a wrong rule can be found and corrected instead of argued about.
Who looks after this when a vendor changes their API?
Vendors deprecate API versions, usually with notice, and that is the most common reason an integration that ran happily for months suddenly stops. The documentation lists every endpoint and mapping so any developer can take it on, and some clients keep that on a support arrangement with us while others handle it in house. Either works, as long as somebody is reading the vendor's notices.
Is this a one-off project or something ongoing?
The build is a project with an end. Keeping it healthy is closer to maintenance, because the things that break an integration are outside your control: an expired credential, a new rate limit, a vendor's scheduled change. Both arrangements are fine, but it is better to decide which one you are in at the start than to find out when something has silently stopped syncing.
Web apps
Related services
Ready when you are
Tell us what you are building and we will tell you honestly how we would approach it.