About

One payment tunnel for the whole ecosystem

Protocol is the central payment tunnel for the Soedja ecosystem. Every company that transacts — Bianglala, Arah, SheetBot, and the ones after them — charges through one account, one integration, one signed webhook. It is deliberately boring infrastructure: stable, explicit, and auditable end to end.

What Protocol is

Protocol is a single payment tunnel that sits in front of one payment processor and serves many merchants — the companies of the Soedja ecosystem. A merchant never talks to the processor directly. It calls Protocol, and trusts a signed webhook back from Protocol when money moves.

That is the whole idea: one hardened tunnel, shared. Credentials, signing, idempotency, and the audit trail live in one place instead of being re-implemented — and re-broken — inside every product.

Protocol is infrastructure, not a storefront. It moves money and records that it did; it does not model catalogues, carts, or inventory. What was sold is passed in on each charge and stored as-is.

Why it exists

Payment code is where small mistakes become expensive ones. Duplicate charges, replayed webhooks, a leaked key, an amount rounded as a float — each of these is a real loss, and each is easy to get wrong when every team wires up payments on its own.

Centralising that surface means it gets built carefully once. When in doubt, Protocol chooses the safer, more explicit option over the clever one — because the cost of being wrong here is paid in someone’s real revenue.

The Soedja ecosystem

Soedja is a family of products under one company. Each is its own business with its own customers, but they share plumbing rather than rebuild it. Protocol is the payments plumbing.

Merchants integrate once and get charges, hosted checkout, statuses, and signed webhooks — the same contract for every product.
Isolation is the hard rule. A merchant, once it can log in, sees only its own transactions, deliveries, credentials, and payouts — never another company’s. That boundary is enforced at the data layer, not left to application code to remember.
Sandbox and production are separate. Test money and real money live in different places and never share a table.

How it works

The integration is three moving parts, and that is the entire surface:

Create a charge — a merchant’s server calls POST /v1/charge and gets back a redirect URL.
Redirect to pay — the customer pays on the processor’s hosted checkout. No card data ever touches a Soedja server.
Receive a webhook — Protocol posts a signed notification the moment the payment settles, fails, or expires. The merchant fulfils on that.

The full contract — fields, headers, statuses, and how to verify a webhook — lives in the integration guide.

Principles

A few rules never bend, because they are what make the tunnel trustworthy:

Principle	What it means
Persist before you process	Every inbound notification is written down before any logic runs. Audit and idempotency depend on it.
Verify every signature	A payment notification that fails verification is never processed.
Forward-only	A transaction moves forward through its states and never regresses.
Every side effect is idempotent	Re-delivering the same event, or retrying a charge, changes nothing twice.
Fail closed	An unknown merchant, an inactive key, a malformed request — all are denied, never assumed good.
Tenant isolation	A merchant can only ever see its own data. Enforced at the data layer.

Who operates it

Protocol is built and operated by PT Soember Djaya Masyarakat, the company behind the Soedja ecosystem. One legal entity holds the merchant account; every product transacts under it through Protocol.

Get in touch

Questions about integrating, or about becoming a merchant on Protocol? Reach us through the contact page.

Building on Soedja? Create an account — sandbox is instant, and the dashboard walks you through your first charge.