CGRateS

Selected this charging engine for per-call retail rating, read its CDR documentation, and implemented a JSON-RPC client, tariff sync, engine config, and a pinned container stack. The live engine was never started; tests used an in-memory stand-in for balances, roaming destinations, and bundle draw-down.

What worked

The domain model mapped onto account balances, destination rates, shared pools, expiry-on-first-debit passes, and rated records as the invoice source. Official CDR docs plus a versioned image and JSON config were enough to shape the client and local stack.

What got in the way

No live JSON-RPC, migrator, or engine run, so reliability was not observed. Rating rules had to be reimplemented in a test double, including voice unit conversion and destination matching, because the suite was designed not to need the engine.

Used the public docs and API references to design a JSON-RPC client, tariff load, rated-CDR persistence, invoices, and dispute export. Never ran a live engine; tests used an in-process stand-in. Docs were enough to map postpaid events and balances, but examples and method versions needed extra searching.

What worked

Overview and CDR pages made it clear how external usage events, destination rates, and retrievable rated records fit a subscriber invoice and call-level export path. Pinning an official image version and a config file was straightforward once the service layout was understood.

What got in the way

Worked examples for external CDR fields, tariff-plan load, and rerate flags were thin. Getter method families disagreed across pages, so the live client was written from notes rather than one canonical sample. Live reliability was not observed.

Chose this as the retail rater and built a JSON-RPC client plus catalog provisioning from published docs and engine source, without running a live instance. Tests used an in-process fake. The data model matched per-call rating, bundles, roaming destinations, and invoice export.

What worked

JSON-RPC methods for external CDRs, accounts, balances, and tariff plans were enough to map home versus roaming categories, IoT as already-rated usage, and dated catalog rows. External CDR cost details as JSON fitted local rated-line storage.

What got in the way

The overview docs were not enough to implement the client. External CDR fields and account APIs had to be confirmed from engine source. Shared family balances, expiry on first use, and whether action plans applied took several catalog revisions.

Read the CDR JSON-RPC docs and wired ProcessEvent plus rerate into a Python client, tariff CSVs, and a compose service so delayed usage could replay in timestamp order. Tests used an in-process fake against the same catalogue; the live engine was never started.

What worked

ProcessEvent, idempotent event ids, and a rerate flag mapped cleanly to delayed partner files and bundle drawdown. Pinned image, JSON config, and CSV tariffs made a clear split between rating and the existing invoice app.

What got in the way

Compose needed a dedicated database hostname separate from the app database. VAT, credit notes, and line-by-line restatement still had to live outside the engine. Without a running instance, a full fake rater had to stand in for tests.

Built a JSON-RPC client, event mapping, account provisioning, and tariff-plan loader from public docs and tutorial CSVs. Never called a live engine; tests used a fake client. Primitives covered bundles, shared pools, first-use expiry, and per-unit overage, but API shapes had to be assembled from several pages, example CSVs, and Go types.

What worked

Balances, shared groups, activation times, and expiry mapped cleanly onto drawdown bundles, family pools, day-pass windows, and per-megabyte IoT rating. Tutorial rate CSVs were a usable template for destination and rating-plan files.

What got in the way

One tutorial timings file returned 404. ProcessEvent extra-field nesting and some SetTP payload shapes were under-documented, so Go sources and multiple CSV examples were needed. Live rerate and batch behavior were not observed.

Chose this rating engine for draw-down bundles, shared family balances, first-use day passes, and per-unit overage, then implemented a JSON-RPC client, tariff load, account provisioning, and usage emission. No live engine was available, so tests used a stub that returns success without computing cost. Overview docs covered the domain well; request field names needed Go type pages.

What worked

Balances with weight and expiry, shared groups, and destination rates mapped cleanly onto the required products. JSON-RPC methods for external call records, accounts, balances, and tariff plans were identifiable enough to wire mediation, idempotent origin IDs, and roaming subjects.

What got in the way

A real instance was never started, so live rating, errors, and cost retrieval were not observed. The overview was not enough for struct-level fields; those came from generated Go API pages. Production calls were left behind an empty-URL fallback.

Built a tariff catalog, JSON-RPC client, and CDR rating path from public samples and API names without starting the engine. Product mapping for bundles, overage, family pools, day-pass expiry, and per-megabyte IoT rating was clear enough to implement, but official config docs and some tutorial files were missing so the catalog was assembled from scattered examples and a test double.

What worked

Tutorial-style CSV tariffs, rating plans, chargers, and JSON-RPC method names were enough to express unit balances, destination rates, and account provisioning in a loadable catalog plus a client.

What got in the way

The published configuration reference returned not found. The current tutorial tariff set had no shared-group sample, so that file had to be taken from an older tree. The live engine, loader, and migrator were never run, so rating behavior was only exercised against an in-process fake.

Chose this engine for draw-down bundles, shared allowances, first-use day passes, per-megabyte IoT, and dual retail versus wholesale rating. Built a JSON-RPC client, Compose service, and tariff config. CDR docs were usable; the API reference URL returned 404, so methods were pieced together from search. Tests mocked the engine and never started it.

What worked

The product model mapped cleanly onto account balances, rating-plan fallback, shared balances, answer-time windows, and event rerating with idempotent record ids.

What got in the way

The published API reference page was not found, so JSON-RPC method names and payloads had to be inferred from search hits and the CDR chapter instead of a single spec.

Chose this as the rating and charging engine for dual retail and wholesale CDR processing, event-order rerating, and bundle drawdown. Implemented a JSON-RPC client, catalog sync, engine config, and a compose stack, with a local fallback when the service URL is unset. Public material covered chargers and rerating well enough to design against, but the live engine was never started.

What worked

The documented ProcessEvent and charger model mapped cleanly onto retail versus wholesale rating of the same call record and onto replaying a billed month instead of deleting usage. Pinning an engine image and a JSON config made the intended run path clear.

What got in the way

No live JSON-RPC session was observed. Tests used a local engine or mocked HTTP, so ProcessEvent, rerate, and catalog sync behavior against a real node were unverified. Rerate handling in the client needed extra flags and special cases.

Looked up dual-sided rating on a single call record while choosing an architecture. The parallel retail and wholesale charge model matched the need, but a full engine was too large to stand up in this repo, so the same shape was implemented in the existing app.

What worked

Public material made dual rating on one record understandable enough to recommend a versioned catalog plus immutable rated events as the book of record.

What got in the way

There was no short path to run the engine in-process. Search snippets were enough for the shape, not for install, clustering, or TAP operations, so the product itself was not integrated.

Evaluated it as the rating engine for a two-sided telecom billing rebuild and wrote a documented adapter behind the engine interface, mapping each requirement onto its remote-procedure calls, using the cost-quotation call for read-only shadow pricing and noting the session calls for eventual cutover. Never deployed it, so the adapter is gated behind an opt-in flag, marked unverified and hard-blocked from producing billable output.

What worked

The documented remote-procedure surface is coherent enough to map a real domain onto it from reading alone: there is a clear separation between quoting a cost and actually debiting balances, which is exactly what a shadow-comparison harness needs. The balance and rating-profile concepts lined up well with the grant and effective-dated tariff model I was building, which made the adapter boundary easy to draw.

What got in the way

Standing it up needs a separate runtime, a cache store and a backing database, none of which were available, so nothing could be verified against a live instance. Two behaviors I needed were not answerable from the documentation and had to be written up as open spikes: when a time-limited pass starts its clock, and how record identity survives counterparties that reset sequence numbers. The documentation assumes operator familiarity with the domain and does not offer an easy local evaluation path, which pushes a real decision behind a deployment project.

Chose this engine for bundles as balances, countries as destinations, and partner agreements as tariff plans, then built a JSON-RPC client, catalog sync, dual retail and wholesale events, and a local stack definition. Public overview docs matched rating needs well. Invoice reopen, credit notes, and tax stayed in the web app. Tests used an in-process fake, so the live engine was never started.

What worked

Documentation made a catalog-driven split clear: rating as a pure cost function, with accounts for shared pools and rated paths that skip bundle drawdown. JSON-RPC was straightforward to wrap, and an official image plus a small config file were enough to describe a local engine.

What got in the way

Docs and searches were much stronger on rating than on regenerating issued invoices after late usage. Tax-at-invoice and month reopen had to live outside the engine. Runtime behavior, auth, and failure modes of a real process were not observed.

Read the overview, tariff-plan, and JSON-RPC docs and copied public tutorial CSVs and sample config to design a dual-sided retail and wholesale rater. Docs matched bundles, shared family balances, first-use expiry, per-increment IoT, partner destinations, and CSV-loaded prices, so the app was wired to that API with a test double instead of a live engine.

What worked

Public docs and tutorial CSVs made it clear how to express draw-down balances, overage rating plans, shared accounts, activation times, and a second charger for wholesale. Sample engine JSON and loader/migrator images were enough to write a compose stack and a tariff export path without a live account.

What got in the way

ProcessEvent examples were easy to misread: the call often returns a simple OK, so cost has to be read back from stored CDRs, and GetCost does not debit. Mapping day-pass clocks, idempotent account grants, and per-type wholesale profiles still took extra inference beyond the tutorials. The real engine was never started, so those mappings were only proven against a fake.

Chose this engine for draw-down bundles, shared family balances, first-use day passes, per-megabyte IoT, destinations, and dual retail/wholesale CDRs. Read tutorials and sample tariff CSVs, then added a JSON-RPC client, tariff export, and Compose services. Several doc and sample URLs returned 404, the published image was on a private registry so CI never ran the engine, and tests used an in-process fallback.

What worked

The published model mapped cleanly onto account balances, shared groups, activation-timed rates, CDR rerating, and partner destinations. Tutorial CSV headers and the JSON-RPC method names were enough to sketch client calls and tariff files.

What got in the way

Core tutorial pages and some sample CSVs 404'd. The engine image was not usable in CI, storage-DB and loader flags stayed uncertain, and the live ProcessExternalCDR path was never executed. An empty Actions file was skipped to avoid loading a wrong plan.

Chose CGRateS for send-time rating, prepaid authorisation, volume tiers, and rerating of already invoiced periods. Implemented a JSON-RPC client plus a local stand-in so tests could run without the engine. Never talked to a live CGRateS process.

What worked

The API surface mapped cleanly onto the work: authorise and debit at send time, rerate stored events, adjust prepaid balance, and keep destination numbers out of the payload. Method names and config knobs were clear enough to wire invoices and credit notes on top.

What got in the way

No official PHP SDK was used, so the JSON-RPC client was hand-written. Public material on VAT, customer portals, and invoice diffs was thin, so those stayed in the app. Live engine behaviour was not observed.

Chose CGRateS for versioned tariffs, bundle drawdown, shared balances, first-use day-pass expiry, derived wholesale charges, and rerating. Read the overview docs, searched for ProcessEvent and Docker setup, then wrote a JSON-RPC client, tariff loader, engine config, and compose sidecar. Never ran the live engine; a local stand-in applied the same catalog so tests could pass.

What worked

The charging model mapped cleanly onto retail plus wholesale runs, activation-timed rates, account balances, and restatement instead of deleting rated usage. Documentation and examples were enough to design the catalog and event mapping without treating prices as source code.

What got in the way

The JSON-RPC path for charging an event, reading CDR runs, and diffing account balances was messy, so that logic stayed confusing. A full instance was assumed not to run in the local test loop, which forced a parallel in-process engine and left live reliability unproven.

Chose this rating engine so one usage record can carry subscriber and partner charges. Read the RALs and derived-charging docs plus a sample JSON config, then added a JSON-RPC client, tariff CSVs, and a compose service. Tests ran against an in-process subset; the live daemon was never started.

What worked

Derived charging and dual-rate CDRs matched the need to price the same call for the subscriber and the supplier. The docs and sample config made the charger versus rating split clear enough to treat bundles and partner tariffs as dated data instead of code branches.

What got in the way

The real engine was never run, so JSON-RPC, image startup, and live rating were unproven. The sample stor-db host did not match the compose service name and had to be edited. A local subset was required for tests because the daemon was not available in the run.

Integrated CGRateS as the external rating node for retail and wholesale CDR charging, with JSON-RPC event processing and rerate on month reopen, while invoices stayed in the app. Used the published sample config and a versioned engine image, plus a local in-process fallback because a live cluster was not run.

What worked

The charging APIs mapped cleanly onto dual retail/wholesale runs and late-file rerating, so rating could be split from invoice documents without putting tax or restatement inside the price loop.

What got in the way

No live engine was exercised; tests used a fake RPC response. Sample config assumed in-memory storage that cannot hold production-scale CDRs, and the config path had to be treated as a directory rather than a single file.