Payment gateways
eSewa, Khalti, Stripe, PayPal and bank gateways, including callbacks, verification and refund handling.
API integration — Nepal
API integration from Nepalbuilt for the failure cases
Soft Himalaya connects payment gateways, CRMs, ERPs, couriers and custom APIs from Kathmandu for businesses in Nepal, the UK, Australia, the USA and Canada.
- Field mapping and record ownership agreed first
- Retries, duplicates and timeouts handled deliberately
- Logging and alerts so failures surface early
Engineering for real systems
Field ownership, credentials, retries and alerts are designed before data moves between systems.
- Contract first
- Endpoints, fields and error shapes are agreed and documented before either side writes code against them.
- Safe to retry
- Writes are made idempotent so a repeated call after a timeout does not create a duplicate order or payment.
- Failures are visible
- Integrations log and alert when a third party is down, rather than failing quietly and losing records.
- Credentials handled properly
- Keys live in environment or secret storage, never in the repository, and are scoped to what the integration needs.
What we integrate
Connecting the systems you already run
Most integration work is not exotic. It is making two systems agree on what a customer, an order or an invoice is, and handling the cases where one of them is unavailable.
CRM and sales tools
Contacts, deals and activity synced between your website, forms and the CRM your team works in.
ERP and accounting
Invoices, inventory and ledger records exchanged with the accounting or ERP system of record.
Logistics and delivery
Courier booking, label generation, rate lookups and tracking status pulled back into your own interface.
SMS, email and notifications
Transactional messaging through providers, with delivery status and retry behaviour handled explicitly.
Marketplace and channel sync
Catalogue, stock and order synchronisation between your platform and the marketplaces you sell on.
Custom REST and GraphQL APIs
APIs built for your own products or partners, with versioning, authentication and documentation.
Webhooks and event handling
Inbound events received, verified, queued and processed so a burst of traffic does not drop records.
Legacy and database bridges
Older systems exposed through a defined interface instead of allowing direct access to their database.
Why it matters
The cost is in the failure cases
Connecting two systems on a good day is straightforward. The work worth paying for is what happens when a provider times out, changes a field, rate-limits you or sends the same event twice.
Manual re-entry is expensive
Staff copying orders between systems is slow and produces mismatches that surface weeks later during reconciliation.
Third parties go down
Providers have outages and maintenance windows. Queues, retries and clear fallback behaviour keep your side working while theirs recovers.
Duplicates are the usual bug
A timeout does not mean the call failed. Without idempotency keys and reconciliation, a retry becomes a second charge or a second shipment.
APIs change
Fields get deprecated and versions retire. Integrations need monitoring and an owner, not a one-time build and a hope.
How we work
Map it, build it, then break it on purpose
Timelines depend on the provider's documentation quality, sandbox availability and how quickly credentials and approvals come through — often the slowest part of the work.
- 01
Discovery and documentation review
We read the provider's API docs, confirm what your plan actually allows, and identify rate limits, sandboxes and approval steps.
- 02
Data mapping and contract
Fields are mapped between systems, the source of truth for each record is decided, and the interface is documented before implementation.
- 03
Sandbox implementation
The integration is built against the provider's test environment with credentials kept out of the codebase from the start.
- 04
Error and retry design
Timeouts, partial failures, duplicate events and rate limits are handled deliberately, with idempotency where records are created.
- 05
Testing the failure paths
We test the unhappy cases as well as the happy one: provider down, malformed response, replayed webhook, expired credential.
- 06
Deployment and monitoring
The integration goes live with logging, alerting and a documented runbook so a failure is noticed by you before it is noticed by a customer.
Integration planning
Four decisions every integration needs
Rather than showing invented dashboards of requests we have processed, these are the decisions that determine whether an integration is reliable or a recurring support ticket.
Authentication model
API keys, OAuth or signed requests — plus how credentials are rotated and who holds them.
Data mapping
Which system owns each field, how records are matched, and what happens when both sides change the same record.
Failure behaviour
Retry policy, backoff, dead-letter handling and what the user sees while a provider is unavailable.
Monitoring and alerts
What is logged, what triggers an alert, and who is expected to act when an integration stops.
Credentials and provider accounts are registered in your business's name, so access does not depend on us.
Tools
What we build with
Stack choices follow the systems being connected and what your team can maintain afterwards.
Node.js and TypeScript
Integration services, webhooks and API layers
Laravel and PHP
Integrations inside existing PHP applications
Python
Data-heavy syncs and scheduled jobs
REST and GraphQL
Interface design, versioning and documentation
Queues and workers
Retries, backoff and burst handling
PostgreSQL and Redis
Record storage, idempotency keys and caching
Security and reliability
Practices, not guarantees
No integration is unbreakable, and any agency claiming a security guarantee is overselling. What we can commit to is a set of practices applied consistently, and a clear account of what an integration does with your data.
Credential handling
Keys live in environment variables or a secret store, never in the repository, and are scoped to the minimum the integration needs.
Transport and verification
Calls run over TLS, and inbound webhooks are rejected unless their signature verifies against the provider's secret.
Rate limits and backoff
Requests respect the provider's published limits, with exponential backoff and queueing rather than hammering a failing endpoint.
Data and logging discipline
Personal and payment data is logged only where necessary, redacted where it is not, and retained according to what you agree.
Project estimates
Scope first, then price
Cost depends on the provider's API quality, how many systems are involved, whether a sandbox exists and how much reconciliation logic is required. We review the documentation before quoting.
Single integration
One provider connected to one system — a payment gateway, a courier or a messaging service.
- Documentation review
- Sandbox implementation
- Error and retry handling
- Deployment and handover
Multi-system sync
Two or more systems kept in agreement, with ownership rules and reconciliation between them.
- Field and ownership mapping
- Scheduled and event-driven sync
- Duplicate and conflict handling
- Monitoring and alerting
Custom API platform
An API you expose to partners or your own applications, with versioning and documentation.
- Interface design
- Authentication and rate limits
- Published documentation
- Support and versioning plan
Questions
Frequently asked questions
Common questions about providers, timelines, failure handling and how integration work is quoted.
It is connecting two systems so they exchange data without anyone re-keying it — a website to a CRM, a store to a courier, an application to a payment gateway. Most of the work is deciding which system owns each record and what happens when one of them is unavailable.
Working together
A clear integration relationship
We do not publish anonymous client quotes, uptime percentages or request-volume graphs that cannot be verified. These are the standards we hold ourselves to instead.
Documented interfaces
The fields, endpoints, error codes and retry behaviour are written down and handed over, not held in one developer's head.
Credentials stay yours
Provider accounts are opened in your business's name, with our access scoped and removable.
Failure cases tested
We show what happens when a provider is down or returns an error, not only that the happy path works.
Handover you can maintain
Source code, environment configuration and a runbook for common failures go to whoever supports the system next.
Start a project
Tell us which systemsneed to talk
Send the systems involved, links to the provider's API documentation if you have them, and what currently happens manually. We will reply with questions, a suggested scope and an estimate.