Integration differs from the rest of the code in one respect: you do not control the other side. A payment provider, a CRM, a delivery service or a government registry can respond slowly, respond wrongly or not respond at all. The product has to behave sensibly in each of those cases, or someone else's outage turns into your lost money and customers.
This is the seventh stage of our app development strategy. Below: what we connect, what you get, how much payment gateway, CRM and third-party service integration costs, and why the key question here is not "how do we connect" but "what happens when it fails".
What happens at this stage
- Connecting third-party APIs.
- Integrating payment systems.
- Integrating CRM, maps and external services.
- Web-Sockets for chats and real-time data exchange.
Before writing code we study the other side's documentation, its test environment and its pricing limits. Sometimes that review changes the choice of provider before any money is spent.
What you get at the end
- Working connections to external systems in both test and live mode.
- Documented failure scenarios: what the product does if the other side is unavailable or returns an error.
- An exchange log: what was sent out, when, and with what result.
- Integration settings that can be changed without touching code, where the specification calls for it.
Integrations we have built
| Integration type | What needs thinking through | Example from our work |
|---|---|---|
| Payment systems | payment status, repeated notifications, refunds, subscriptions | Stripe in Vorfahr and FitProt, a WayForPay subscription in Rapport |
| CRM | which data is sent, what to do if the CRM is down | FitProt landing page leads sent to AmoCRM, a separate CRM at Prime EVA |
| Maps | geolocation, places, routes | OpenStreetMap and Leaflet in Internet City |
| External and government services | documentation, test environment, electronic signatures | eHealth in Evrika, government integration and digital signatures in Taxer |
| Real-time exchange | reconnection, message order and delivery | internal chats and notifications in NorthWest |
How much payment gateway and service integration costs
In the Ingello price list the integrations stage costs from $0 to $4,700 and is included only when needed: if the product does not need external systems, the stage is not charged. The price is fixed before work starts. Within the range it is determined by:
- how many external systems are connected and which way the data flows;
- the quality of their documentation and whether a test environment exists;
- how complex the money scenarios are: one-off payment, subscription, refunds;
- real-time requirements: chats, statuses, notifications;
- how many failure scenarios have to be handled and logged.
The key integration question: what happens when it fails
The payment went through, but the confirmation never arrived. The order was created, but the CRM is down. These are the scenarios that decide whether a business loses money, and they are exactly the ones usually missing from the specification. That is why we raise them at the technical specification stage, not at the first incident.
Technically the answer is usually the same: a queue and a retry instead of an immediate failure, plus a log of everything sent out. A retried request must not create a second payment or a second order. Logging is covered in more detail in our article on events and notifications.
Example: a factory with seven integrations
The Polish car mat manufacturer Prime EVA sells through an online shop, while the company's software works with external services. They include the WAPI fulfilment service, Microsoft mailing, a car model database, a barcode registry and a separate CRM. Each service has its own rules, its own failures and its own pace. Orders arrive at the same time, production and delivery change their statuses, and some tasks have to run later: an email to the customer, a status update, a repeat request.
We built process monitoring so that a stuck order or a failed integration shows up immediately, not when a customer complains. The delivery module linked orders to WAPI: shipping labels, dispatch, parcel statuses. The outcome: the failures that left orders stuck between the shop, production and delivery stopped quietly costing the company customers.
Choose the provider before writing code
In the XenFit online training platform, video calling was the most expensive piece. Before development we compared nine options, from a self-hosted Jitsi server to ready-made APIs. It turned out that in one case group calls were only available on a plan costing around five hundred dollars a month, in another the service handled signalling only and stored no recordings, and in a third the free conference ended at the 45th minute, right in the middle of a workout.
What breaks if you cut corners
The product becomes hostage to someone else's uptime. An outage at an external service becomes an outage for your business, and the incident cannot be investigated because nobody recorded what was actually sent. Money is charged but no order exists. A lead was sent but never reached the CRM. Each case is sorted out by hand and costs you customer trust.
What we need from you
- Contracts or connection requests with the payment provider and other services.
- Access to their test environments and documentation, and a technical support contact.
- A decision on which data is the master copy in your system and which lives in the external one.
Where next
Next comes server-side business logic. The previous step: interface logic. The map of all stages is in the app development strategy.
Need to connect payments, a CRM or a government service? Let us discuss your integrations at a free consultation with an architect, and afterwards you will receive a price and timeline estimate broken down by stage.
