Ecommerce integrations that stop the re-typing
Somebody in your office copies every order into Tally, then into the courier panel, then updates a stock sheet. That person is your integration, and they make mistakes because humans do.
We connect the systems properly, including the unglamorous parts: what happens when the ERP is down, and how you find out that a sync failed.
First thing we check is whether your system actually has an API. That answer changes the timeline more than anything else.
The version most Pune businesses are running today.
- Order arrives, someone copies it into Tally
- Then again into the courier panel for a label
- Stock sheet updated, sometimes the same day
- Marketplace still shows the item in stock
Invoice raised, label printed, stock reduced everywhere, customer told. Your team handles exceptions instead of data entry.
Six integrations, and what each one really involves
Pick one to see what it covers, how hard it typically is, and the question that decides the timeline.
Payments and COD
A standard integration on every platform we build. The work is less about code and more about getting the rules right for how you actually sell.
Your KYC and gateway approval, which is paperwork on their side rather than development on ours. Start it early.
- UPI, cards, netbanking and wallets
- COD limited by pin code, order value or product
- Partial prepaid to reduce return losses
- Refunds and failed payment handling
- Reconciliation against settlement reports
Courier and shipping
Rates, labels, pickups and tracking, so dispatch happens from your admin rather than from four browser tabs.
Whether you use an aggregator or several couriers directly. One aggregator is far simpler than four separate APIs.
- Serviceability and rate calculation by pin code
- Label generation and pickup requests
- Tracking page your customers can read
- Weight and dimension rules for packaging
- COD remittance reconciliation
Tally and accounting
Orders and invoices flowing into your books without anyone re-keying them, with GST handled properly rather than approximately.
Where Tally runs. A machine reachable over the network is straightforward. An office desktop switched off at 7pm needs a different approach.
- Sales vouchers created from orders
- GST rates, HSN codes and place of supply
- Ledger and item mapping agreed up front
- Credit notes for refunds and returns
- A reconciliation view when numbers disagree
ERP and inventory
The most valuable and the most demanding. Stock, prices and orders synchronised between the store and the system your operations already run on.
What your ERP will actually expose, and whether you can get a test environment. This decides the timeline more than the code does.
- Stock read from the ERP on a schedule or on demand
- Orders pushed once, with duplicate protection
- Dealer pricing and customer records for B2B
- Dispatch and invoice status returned to the store
- Middleware where the ERP has no usable API
Amazon and Flipkart
Selling the same stock in three places is how overselling happens. One inventory pool, updated everywhere, prevents most of it.
Whether your product identifiers match across channels. If they do not, that mapping is the project before any sync begins.
- Single stock pool across store and marketplaces
- Listing and price synchronisation
- Marketplace orders pulled into one dashboard
- Channel-specific pricing rules where you need them
- Alerts when a listing gets suppressed
WhatsApp and CRM
Order updates where your customers actually read messages, and enquiries landing in your CRM instead of one person's inbox.
WhatsApp Business API access and message template approval, which takes a few days and has a small monthly cost.
- Order confirmation and dispatch updates
- Abandoned cart reminders
- Enquiries pushed into your CRM with source tracking
- Two-way replies routed to the right person
- Opt-out handled properly
Which system owns the truth?
Almost every integration disaster traces back to skipping this question. When two systems both think they own the stock number, they will eventually disagree, and then somebody has to decide which one was right.
We write down, field by field, which system is authoritative and what happens when they conflict. That document is short, boring, and it is the difference between an integration that works and one that quietly corrupts your data.
Stock
Usually the ERP or the warehouse system, because that is where physical reality is recorded. The store reads it and never writes back except to reserve.
Price
Depends on your business. Retail price often lives in the store, dealer rates almost always in the ERP. Both is fine, provided the boundary is explicit.
The order
Created in the store, then pushed once and only once. Duplicate orders in accounting are the most common symptom of a retry loop nobody designed.
Product data
Codes and specifications from the ERP, descriptions and images from the store. Trying to author marketing copy inside an ERP never survives contact with a marketing team.
The customer record
Usually the store for B2C and the ERP for B2B, because a dealer already exists in your books long before they log in.
Every integration fails eventually. The question is what happens next.
This is the part cheap integration work leaves out, and the part that decides whether you trust your own numbers a year from now.
Retries that do not duplicate
If the ERP is unreachable, the order waits and tries again. Each attempt carries an identifier so a retry cannot create a second invoice.
Alerts to a person
A failure that only appears in a log file is a failure nobody knows about. Someone named gets told, on a channel they actually read.
A readable audit log
What was sent, when, and what came back. When accounts and the website disagree about an order, this settles it in minutes rather than days.
A manual override
Your team can pause a sync, re-send one order or correct a record without waiting for a developer. Rare, but essential the day you need it.
Conflict rules agreed up front
If the store says four in stock and the ERP says two, we already know which wins and whether anyone gets warned about it.
A test environment
We do not develop against your live accounting data. If your ERP cannot provide a sandbox, that constraint shapes the whole approach and we will say so early.
What we cannot promise about integrations
Integration work depends on software we do not control. Anyone who guarantees these has not read the other system's documentation.
That your ERP has an API capable of what you want. Some expose almost nothing, and no amount of budget changes that
Instant sync everywhere. Most systems are polled on a schedule, and near real time is usually the honest promise
That a third party will not change their API. They do, and when it happens the fix is chargeable work
That messy data will survive the journey. If your product codes do not match between systems, that is a cleanup project first
That we can fix problems inside their software. We will help you chase their support, but we cannot patch it
What we do promise: we check all of this before quoting, so the constraints appear in the proposal rather than in month three
Integration questions we get first
Ask anything else on WhatsApp. If you know your ERP's name, mention it and we can usually answer straight away.
Can you connect our store to Tally?
Usually yes. The practical questions are which Tally version you run, whether it is on a machine reachable from the internet or sitting on an office desktop, and whether your product codes and ledger names match what the store will send. The last one is the usual delay, and it is a data cleanup task rather than a development one.
Do we need two-way sync?
Less often than people assume. Stock flowing from the ERP to the store and orders flowing from the store to the ERP is technically two one-way flows, and it solves most problems. True two-way sync on the same field, where either side can change it, is where conflicts and duplicates come from. We use it only where the business genuinely needs it.
Our ERP vendor says they will handle it. Should we let them?
Sometimes that is the right call, and we will work alongside them rather than compete for it. What matters is that one party owns the whole path end to end. The projects that fail are the ones where the ERP vendor builds half, we build half, and nobody owns what happens when an order goes missing between the two.
How long does an integration take?
A payment gateway or a courier aggregator is routine and quick. An ERP sync depends almost entirely on access. Getting API credentials and a test environment from an ERP vendor regularly takes longer than writing the integration itself, which is why we start that conversation before scoping anything else.
What if our system has no API at all?
There is usually still a path. Scheduled file exchange, a database view, or an export folder that gets picked up on a timer. It is less elegant and it is not instant, but it removes the manual re-typing, which is the point. We will tell you honestly what the compromise looks like before you commit to it.
Who fixes it when it breaks?
Integrations are the most common reason clients take a maintenance plan , because they depend on software that changes without warning. Whether that is us or someone in-house, it needs to be somebody specific, with access to the alerts and the audit log. An integration nobody watches will eventually fail silently.
Which system is somebody re-typing into today?
Name the systems and we will tell you what is realistically connectable, what is awkward, and what would need a cleanup first.
hello@ecommercepune.in
We will check what your system can realistically expose and come back with an honest view, including if the answer is a scheduled file exchange rather than a live API. If it is urgent, call or WhatsApp +91 88620 92781 .