TallyPrime and BigCommerce integration

What moves between them

The main flow runs from BigCommerce into TallyPrime. When an order is paid, ml-connector creates or matches a Sundry Debtors ledger for the shopper and posts the order as a Sales voucher in TallyPrime, then records the payment as a Receipt voucher and any BigCommerce refund as a credit entry. Product data moves the other way: stock items and standard prices maintained in TallyPrime are published to the BigCommerce catalog so the storefront reflects the inventory master. Order and customer changes are driven by BigCommerce webhooks with a Day Book poll as backstop, while catalog pushes run on a schedule you control.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the BigCommerce access token in the X-Auth-Token header on every REST call, while reaching TallyPrime through a local agent on the customer's network because port 9000 is not internet-reachable and the TallyPrime application must be running with the target company open. BigCommerce order webhooks are verified against the X-BC-Signature HMAC-SHA256 before processing, and since each payload only carries a resource type and ID, ml-connector immediately fetches the full order from the REST API. The BigCommerce customer maps to a TallyPrime Sundry Debtors ledger, the order to a Sales voucher with line items as inventory allocations, and totals and tax to the matching ledgers, with all dates converted to TallyPrime's strict YYYYMMDD format. Because TallyPrime has no idempotency keys, ml-connector tracks which orders it has already imported so a re-delivered webhook does not create a duplicate voucher, and re-imports of an existing ledger or stock item update in place. BigCommerce rate limits return HTTP 429, so calls back off and retry, and since TallyPrime cannot push events the Day Book is polled on a schedule to catch anything a webhook missed.

A real-world example

A mid-sized Indian consumer goods seller of around fifty staff runs TallyPrime for accounting, inventory, and GST and sells direct to shoppers on a BigCommerce store. Before the integration, an accounts clerk exported the day's web orders and keyed each one into TallyPrime as a Sales voucher by hand, set up new buyers as ledgers, and reconciled payments and refunds at month end, which was slow and error prone during sale periods. With TallyPrime and BigCommerce connected, each paid order posts into TallyPrime automatically as a Sales voucher against the right customer ledger, payments and refunds follow, and stock levels stay aligned with the catalog. The clerk reviews exceptions instead of re-typing every order, and GST returns draw from books that already match the storefront.

What you can do

• •Post paid BigCommerce orders into TallyPrime as Sales vouchers with line items as inventory allocations.
• •Create or match a Sundry Debtors ledger in TallyPrime for each BigCommerce customer.
• •Record BigCommerce payments as Receipt vouchers and refunds as matching credit entries in TallyPrime.
• •Publish TallyPrime stock items and standard prices out to the BigCommerce catalog.
• •Verify BigCommerce order webhooks by HMAC-SHA256 and reach TallyPrime through a local agent on port 9000.

Questions

Which direction does data move between TallyPrime and BigCommerce?

The main flow is BigCommerce into TallyPrime. Paid orders, customers, payments, and refunds move from BigCommerce into TallyPrime as Sales vouchers, Sundry Debtors ledgers, and Receipt entries. Product data moves the other way, with TallyPrime stock items and prices published to the BigCommerce catalog so the store reflects the inventory master.

How does ml-connector reach TallyPrime if it only has a local server on port 9000?

TallyPrime exposes a local HTTP server on port 9000 that is not reachable from the public internet, so ml-connector connects through a local agent running on the customer's machine or LAN. The agent forwards the XML or JSON envelopes to TallyPrime and relays the responses, and the TallyPrime application must be running with the target company open for any call to succeed.

How are duplicate orders avoided when TallyPrime has no idempotency keys?

BigCommerce can deliver the same webhook more than once, and TallyPrime does not offer an idempotency key or deduplication ID on its HTTP interface. ml-connector tracks which BigCommerce order numbers it has already imported and skips or updates rather than re-creating, so a re-delivered event does not produce a duplicate Sales voucher. Re-imports of an existing ledger or stock item update it in place rather than duplicating.