The safest Tally endpoint is still a local endpoint
TallyPrime's local HTTP/XML interface is useful for reading companies and masters and for importing carefully constructed records. It is not a service that an ecommerce integration should casually publish to the internet.
Port forwarding, a public IP, or a general-purpose tunnel creates an inbound path toward the computer that holds the merchant's accounting data. It also makes connectivity depend on firewall rules and network configuration that are difficult for support teams to verify consistently.
Tally Connect uses a different shape: a small Windows Agent runs beside
TallyPrime and requests authorized work from the cloud over outbound HTTPS. It
talks to TallyPrime only at 127.0.0.1:9000 on that computer.
Let the private computer call out
Outbound HTTPS usually follows the same path the computer already uses for ordinary secure web traffic. The cloud does not initiate a connection to the Tally machine.
The sequence is straightforward:
- Shopify sends an authenticated event to the cloud application.
- Tally Connect validates the event and creates a typed command when local Tally work is required.
- The paired Windows Agent asks for the next authorized command.
- The Agent performs the allow-listed local operation against TallyPrime.
- It returns a structured result, and important writes are verified before the cloud marks them complete.
If the computer is offline, the work waits. The design does not need to make the Tally port reachable from outside the machine just to resume later.
Pair a device without sharing permanent secrets
Setup begins with a short-lived pairing code generated inside the Shopify app. The installer checks cloud availability, the local Tally endpoint, and the loaded company before consuming that code.
After pairing, the Agent receives device credentials for its own authorized connection. On Windows, sensitive local credential material is protected using the signed-in user's DPAPI context. Refresh credentials are stored hashed in the cloud.
The pairing code is not a permanent password, and operators can see and revoke paired devices from the connection workflow.
Keep the Agent's capabilities narrow
A connector should not turn the cloud into a remote console for an accounting computer. Tally Connect accepts known, typed command families rather than arbitrary cloud-supplied XML, TDL, shell commands, or executable scripts.
The local adapter builds requests from validated fields. Writes also check that the company loaded in TallyPrime matches the company name and GUID bound during setup. If the wrong company is open, the command fails closed.
These restrictions reduce the amount of authority a queued command carries:
- known command types only;
- known local Tally address only;
- validated and bounded payloads;
- selected-company identity checks; and
- structured results with explicit terminal states.
Encryption is one part of the boundary
Commands and results may contain operational or accounting data. Tally Connect encrypts command payloads and results in PostgreSQL using authenticated encryption and removes terminal command data after the configured short retention window.
Logs and support diagnostics should not include access tokens, refresh tokens, device credentials, complete customer contact data, or raw Tally responses. The right support artifact is a redacted diagnostic summary and command ID.
Encryption does not replace workflow safety. Preview gates, company checks, duplicate-safe identity, read-after-write verification, pause controls, and reconciliation states are equally important parts of the protection model.
Make connection health visible
The merchant should be able to answer four questions without opening Windows Task Scheduler or inspecting logs:
- Is a connector paired?
- Has it sent a recent heartbeat?
- Which Tally company is bound?
- Is live work enabled, paused, or blocked?
Tally Connect surfaces this state in the embedded app. A stale heartbeat is treated as offline, and work that requires TallyPrime does not pretend to be complete while the local system is unavailable.
The Windows setup application remains useful for repair and diagnostics, but daily operators should see the operational state where they already manage the Shopify connection.
Plan updates without weakening the trust model
A background connector needs a controlled update path. Production installers and update manifests should be signed by the official publisher. The updater must verify the signed manifest and package hash before replacing the Agent.
Private pilot packages are visibly separated from production distribution. An unsigned pilot path should never be presented as equivalent to an Authenticode-signed public release.
Compatibility is also evidence-based. Software support should be distinguished from proof against the merchant's exact TallyPrime family, features, company configuration, and inventory mode.
A practical security checklist
- Keep TallyPrime listening only on the local machine.
- Install the Agent as the same signed-in Windows user who runs TallyPrime.
- Pair from the correct Shopify store and verify the loaded company.
- Never email pairing codes, tokens, raw logs, or Tally responses.
- Revoke devices that are no longer in use.
- Pause sync before repair, removal, or changes to the bound company.
- Use a signed production package before broad distribution.
- Review Activity after connectivity interruptions or version changes.
The goal is not merely to encrypt a connection. It is to make the safest network shape the easiest one for the merchant to operate.
Continue with the security and privacy reference and the Windows Agent operations guide.