# E-Gridium · ChargeBridge (English)

E-Gridium operates ChargeBridge, the OCPI roaming and clearing hub where charge point operators and e-mobility service providers connect once, decide scope explicitly and settle per period.

Electroop and E-Gridium are separate companies operating under common ownership. ChargeBridge is an E-Gridium product.

Where the service stands: Technical connectivity is live for onboarding partners: handshake, data flow and settlement statements. Settlement runs in dry-run until the financial go-live gate closes (data processing agreements with every partner, regulatory registrations, e-invoicing). No partner names or counts are published on this site; connected parties are visible to each other through the hub directory.

## OCPI modules

| Module | Version | CPO | eMSP | Status | Scope |
| --- | --- | --- | --- | --- | --- |
| credentials | 2.2.1 | Sender and receiver | Sender and receiver | Offered | Token A/B/C exchange, version negotiation and endpoint discovery are completed hub-side; inbound and outbound registration are both supported. A completed handshake does not by itself open data flow: an explicitly accepted partner relationship is required. |
| locations | 2.2.1 | Sender | Receiver | Offered | Full and partial (PATCH) updates; per-partner publish scope via sharing sets so a CPO decides which location each eMSP sees. |
| sessions | 2.2.1 | Sender | Receiver | Offered | Session objects with status transitions and charging periods; relayed only along accepted partner relationships. |
| cdrs | 2.2.1 | Sender | Receiver | Offered | Validation against tariff and session, idempotent intake, then entry into the settlement window. Türkiye-specific fields travel in the tr-cdr-additionals extension. |
| tariffs | 2.2.1 | Sender | Receiver | Offered | Energy, time, flat and parking components; per-partner tariff visibility follows the same sharing scope as locations. |
| tokens | 2.2.1 | Receiver | Sender | Offered | Token push and real-time authorize; stored token material is hashed and subject to the retention sweep. |
| commands | 2.2.1 | Receiver | Sender | Offered | Command and asynchronous result routing with ownership and visibility checks: a command reaches a charger only if the eMSP is allowed to see it. |
| chargingprofiles | 2.2.1 | Receiver | Sender | Offered | Profile set, get and clear with asynchronous results; the hub relays, it does not compute charging schedules. |
| hubclientinfo | 2.2.1 | Receiver | Receiver | Offered | Directory of connected parties with role and status; the public website publishes no party list. |
| bookings | 2.3.0 | Receiver | Sender | Offered | OCPI 2.3.0 booking objects routed in both directions along accepted relationships. |
| parking | 2.3.0 | Sender | Receiver | Offered | Bay attributes and restrictions as defined in OCPI 2.3.0; follows location publish scope. |
| payment | 2.3.0 | Sender | Receiver | Offered | The hub relays the protocol objects. It is not a payment institution and does not process cardholder data; money moves between the parties’ own payment providers. |
| tokens (groups) | 2.3.0 | Receiver | Sender | Offered | Group objects as defined in OCPI 2.3.0; authorization follows the group. |
| tr-cdr-additionals | tr-extension | Sender | Receiver | Offered | Utility rate in TRY/kWh, VAT breakdown and the identifiers both parties need for reporting; sent by the CPO alongside the CDR. The profile was authored by ZES as the OCPI-TR custom module specification; E-Gridium implements it and thanks ZES for opening it to the ecosystem. |
| OICP bridge | tr-extension | — | — | Not offered | A bridge exists in the codebase but is not installed in any environment. Partners who need OICP must connect to that network directly. |
| webhooks | tr-extension | — | — | Not offered | Partners receive events through the OCPI modules above; a separate webhook delivery channel is not part of the service. |

Source: https://egridium.com/en/ocpi-modules

## For charge point operators

Publish your locations and tariffs once; decide per partner which eMSP sees which site; receive sessions, CDRs and settlement statements from one place.

### Partners in this role ask for
- Reach drivers of several eMSP apps without a separate integration for each
- Keep control of which sites and tariffs each partner can see
- Get a netting statement per period instead of reconciling partner by partner
- Carry the Türkiye-specific CDR fields without a custom integration

### Modules you use
credentials, locations, tariffs, sessions, cdrs, tokens, commands, chargingprofiles, tr-cdr-additionals, parking-bays

### What you need
- [Technical gate] Signed roaming participation agreement and data processing agreement
- [Technical gate] Legal name, tax number and, where applicable, charging network operator licence number
- [Technical gate] An OCPI versions endpoint reachable from the hub and a Token A for the handshake
- [Technical gate] Sender implementations for locations, tariffs, sessions and CDRs; receiver for tokens and commands
- [Financial gate] tr-cdr-additionals populated on every CDR
- [Financial gate] Collection and invoicing details as set out in the agreement

### How it proceeds
1. **Application and agreement** You apply with your role and versions endpoint; the agreement and DPA are signed; your party is created in the hub directory.
2. **Sandbox and handshake** Credentials are exchanged against the sandbox first; each module is exercised with test data and the gaps are listed before anything is live.
3. **Scope and relationships** You decide which eMSPs see which sharing set; each relationship is accepted explicitly by both sides before data flows.
4. **Flow and statements** Locations, status and tariffs reach your partners; sessions become CDRs; each settlement window closes with a netting statement you can verify against the ledger.

### Scope is a decision, not a default

Sharing sets group your locations; a relationship with an eMSP points at a set. Narrowing or widening the scope is one operation and every change is written to the audit ledger. A location that is in no set is invisible to every partner.

### What the hub does with your CDRs

Each CDR is validated against the tariff and the session, then enters the open settlement window for that partner pair. At close you receive a netting statement; the hub fee is a separate line and is never offset against roaming amounts. Until the financial go-live gate closes, statements are produced in dry-run and no invoice is issued.

### Frequently asked questions
**Do I have to open all my sites to every eMSP on the hub?**

No. The default is closed. You create sharing sets and accept relationships one by one; the hub never publishes a location outside an accepted relationship.

**My charging software is not Electroop’s. Can I still connect?**

Yes. The hub speaks OCPI 2.2.1 and 2.3.0 to any compliant implementation. Electroop products are one of several ways to connect; the hub is operated by E-Gridium independently of which software a partner runs.

**Which OCPI version should I implement?**

Either. The hub negotiates the version with each partner separately and translates between 2.2.1 and 2.3.0 where objects differ, so your partners’ version is not your constraint.

**How are fees charged?**

As a percentage per CDR, split between the two parties of a session, booked as its own line in the statement. The rate is in the participation agreement; it is not published here.

URL: https://egridium.com/en/for-cpos

## For e-mobility service providers

Receive locations, live status and tariffs from every CPO you have a relationship with; push your tokens once; start, stop and reserve through a single command channel.

### Partners in this role ask for
- Show more chargers in the app without integrating each network
- Authorize drivers in real time at partner chargers
- Get one statement per period across all CPO partners
- Keep the driver relationship and the app in your own hands

### Modules you use
credentials, locations, tariffs, sessions, cdrs, tokens, commands, chargingprofiles, bookings, token-groups, payment-sessions

### What you need
- [Technical gate] Signed roaming participation agreement and data processing agreement
- [Technical gate] Legal name and tax number
- [Technical gate] An OCPI versions endpoint reachable from the hub and a Token A for the handshake
- [Technical gate] Receiver implementations for locations, tariffs, sessions and CDRs; sender for tokens and commands
- [Technical gate] Real-time authorize endpoint for tokens
- [Financial gate] Collection and invoicing details as set out in the agreement

### How it proceeds
1. **Application and agreement** You apply with your role and versions endpoint; the agreement and DPA are signed; your party is created in the hub directory.
2. **Sandbox and handshake** Credentials are exchanged against the sandbox; token push, authorize and the command round trip are exercised with the charger simulator.
3. **Relationships** Each CPO relationship is accepted by both sides; from then on that CPO’s shared locations, tariffs and status reach you.
4. **Sessions and statements** Your drivers charge at partner sites; sessions and CDRs arrive through the hub; each settlement window closes with one statement across all your CPO partners.

### Commands with ownership checks

A start, stop, reserve or unlock command is routed to a charger only if your relationship with that CPO includes the location. Results come back asynchronously and are visible in your portal view with the full trace.

### Tokens and retention

Token material pushed to the hub is hashed; encrypted credentials and hashes are deleted as soon as their retention time expires. Authorization decisions remain yours: the hub relays the real-time authorize call to you.

### Frequently asked questions
**Do I get every CPO on the hub automatically?**

No. A relationship has to be accepted by both you and the CPO. Discovery of who is connected comes through hubclientinfo; the commercial step is yours.

**Can I run both roles?**

Yes. A party can be CPO and eMSP at the same time; the hub keeps the two role contexts and their statements apart.

**Is the hub a payment institution?**

No. The hub produces netting statements and payment obligations; money moves between the parties through the collection method set in the agreement. Card data never passes through the hub.

URL: https://egridium.com/en/for-emsps

## For navigation and data providers

Receive locations, status and tariffs that CPOs choose to publish to you; no sessions, CDRs or settlement, because you neither operate chargers nor sell to drivers.

### Partners in this role ask for
- Show accurate charger availability in a map or vehicle product
- Receive one feed instead of scraping or integrating networks one by one
- Respect each CPO’s publishing decision

### Modules you use
credentials, locations, tariffs, hubclientinfo

### What you need
- [Technical gate] Signed participation agreement for the data-consumer role
- [Technical gate] A receiver-only OCPI endpoint for locations and tariffs

### How it proceeds
1. **Application** You apply as a data consumer; the agreement covers use of the data you receive.
2. **Handshake** Inbound registration against your receiver endpoint.
3. **Publish decisions** Each CPO decides whether and what to publish to you; the default is nothing.

### Receiver only

The NSP role has no sender modules. Sessions, CDRs, tokens and commands never reach a data consumer, and the settlement platform does not know the role exists.

### Data use

What you may do with the feed is set in the agreement, not in the protocol. The hub enforces scope; you enforce use.

### Frequently asked questions
**Can I get historical sessions for analytics?**

No. The role is receiver-only for locations and tariffs; session and CDR data belong to the two parties of a session.

**How fresh is status?**

As fresh as the CPO publishes it; the hub relays status updates as they arrive and does not poll chargers itself.

**Is there a fee?**

Commercial terms for data consumers are agreed in the participation agreement.

URL: https://egridium.com/en/onboarding-and-sandbox


## Compliance programmes (not certifications)

- ISO/IEC 27001:2022: in-progress (target 2026-12-31). The hub is operated under an information security management system aligned with ISO/IEC 27001:2022. Audit readiness is tracked control by control; no certification audit has been scheduled yet.
- SOC 2 Type II: planning. Trust Service Criteria are mapped to the same control set; the attestation engagement is in planning.
- PCI DSS SAQ-A: self-assessment. The hub does not store, process or route cardholder data; card payment, where it exists in a partner flow, stays with the partner’s payment provider. The SAQ-A scoping document describes the target architecture.

## Evidence records

- **OCPI 2.2.1 route table** (repo-review, Last verified 2026-10-04): The OCPI adapter mounts controllers for credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles and hubclientinfo under the 2.2.1 version endpoint, with auth, idempotency, rate-limit and audit middleware. Supports: That the nine 2.2.1 modules are implemented and routed in the hub. Does not show: Interoperability with a specific partner’s implementation; that is established per partner in the sandbox and the acceptance checklist. https://egridium.com/en/evidence#ocpi-221-routes-repo
- **OCPI 2.3.0 route table** (repo-review, Last verified 2026-10-04): A separate 2.3.0 version endpoint routes bookings, parking bays, payment sessions and token groups, with a translation layer between 2.2.1 and 2.3.0 partners. Supports: That OCPI 2.3.0 objects are accepted and relayed and that mixed-version partners can be connected. Does not show: Production use of 2.3.0 with a named partner; payment-session objects do not make the hub a payment institution. https://egridium.com/en/evidence#ocpi-230-routes-repo
- **Türkiye CDR extension (tr-cdr-additionals)** (repo-review, Last verified 2026-10-04): A dedicated controller and integration profile carry the utility rate in TRY/kWh, VAT breakdown and reporting identifiers next to each CDR. The underlying OCPI-TR custom module specification (v1.0.0, January 2026) was authored by ZES; E-Gridium implements it as published and credits ZES for the work. Supports: That the Türkiye profile exists as an OCPI extension on both sender and receiver side. Does not show: Regulatory acceptance by any authority; the fields are what the parties need for their own reporting. https://egridium.com/en/evidence#tr-cdr-additionals-repo
- **Settlement window state machine** (repo-review, Last verified 2026-10-04): The clearing platform moves each settlement window through OPEN, GRACE_PERIOD, RECONCILING and CLOSED; late CDRs enter during the grace period and disputes surface before close. Supports: That settlement periods, netting statements and payment obligations are produced by the platform. Does not show: That money has moved between partners through the hub: settlement runs in dry-run until the financial go-live gate closes, and invoicing is fenced until then. https://egridium.com/en/evidence#settlement-window-repo
- **Hash-chained settlement ledger** (repo-review, Last verified 2026-10-04): Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts. Supports: Tamper-evidence of the ledger and the “hub fee outside netting” rule. Does not show: Fee rates or splits; those are in the participation agreement, not on this site. https://egridium.com/en/evidence#ledger-hash-chain-repo
- **Fail-closed partner relationships** (repo-review, Last verified 2026-10-04): No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger. Supports: That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision. Does not show: Contractual data-sharing permissions; those come from the signed agreement and DPA. https://egridium.com/en/evidence#edge-fail-closed-repo
- **Retention sweep for token material** (repo-review, Last verified 2026-10-04): Hashed token data and encrypted credentials are deleted as soon as their retention time expires; the sweep runs on a schedule and is the most conservative setting available. Supports: The delete-on-expiry rule stated on the trust page. Does not show: A data-controller’s own retention obligations; those are set in each DPA. https://egridium.com/en/evidence#kvkk-retention-repo
- **Automated test suite** (test-suite, Last verified 2026-10-04): About 1,500 test files across the OCPI adapter, clearing platform, identity service, roaming mesh and hub portal: unit, contract, end-to-end, property-based and mutation tests. Supports: That protocol flows and settlement logic are covered by automated tests. Does not show: On which release and date the suite last passed; a dated run report will be published when available. https://egridium.com/en/evidence#test-suite-count
- **OpenAPI specifications** (document, Last verified 2026-10-04): Machine-readable API descriptions for the OCPI adapter, the clearing platform and the identity service, published on the developers page. Supports: The endpoint surface a partner integrates against. Does not show: Access: endpoints require partner credentials issued during onboarding. https://egridium.com/en/evidence#openapi-specs
- **Compliance programme status** (document, Last verified 2026-10-04): ISO/IEC 27001:2022 in progress (gap assessment, target end of 2026), SOC 2 in planning, PCI DSS SAQ-A scoped as a self-assessment; the matrix tracks each control’s status and owner. Supports: That the programmes exist and their stated status on the trust page. Does not show: Any certification or attestation: none has been issued for E-Gridium. https://egridium.com/en/evidence#compliance-status-json
- **OICP bridge not installed** (repo-review, Last verified 2026-10-04): The OICP-to-OCPI bridge service is marked installed:false in every environment and has no outbound HTTP client; the launch decision record keeps it out of scope. Supports: The negative claim on the modules page: OICP translation is not offered. Does not show: Any future availability. https://egridium.com/en/evidence#oicp-frozen
- **Webhook endpoints return 501** (repo-review, Last verified 2026-10-04): The seven webhook endpoints answer 501 Not Implemented and were removed from the public path list and the portal navigation by the launch decision record; the delivery chain is not wired. Supports: The negative claim on the modules page: webhooks are not offered. Does not show: Any future availability. https://egridium.com/en/evidence#webhooks-501
- **Engineering footprint of the hub** (repo-review, Last verified 2026-10-04): Twelve services in one monorepo (OCPI adapter, clearing platform, identity, roaming mesh, PKI, map data, sandbox, ops MCP, mocks and migrations), 593 database migrations, 87 architecture decision records, about 1,500 test files, and three OpenAPI documents with 83 paths in total. Supports: That the hub is an engineered, documented system rather than a prototype. Does not show: Production scale, partner counts or service levels; counts describe the codebase, not the traffic. https://egridium.com/en/evidence#engineering-footprint
- **Settlement architecture: agreements, windows, statements, obligations** (document, Last verified 2026-10-04): Bilateral, versioned agreements define cycle, grace period, dispute window, fee allocation, payment automation and FX policy; windows move OPEN → GRACE_PERIOD → RECONCILING → CLOSED; statements move GENERATED → PUBLISHED → ACKNOWLEDGED and are hub-signed; obligations carry debtor, creditor, amount and due date. Supports: The structure described on the settlement page. Does not show: Any rate, amount or that real money has moved; payment automation beyond manual mode is configured per partner after the financial go-live gate. https://egridium.com/en/evidence#settlement-architecture-doc
- **Türkiye profile: binding interpretation of tr-cdradditionals** (document, Last verified 2026-10-04): Eight rules the hub applies where the specification leaves room: unit price semantics and precision, VAT handling, versioned corrections, idempotency responses, discovery via version details, eventual matching with a 24-hour compliance-gap report, serial-number reading, transport security. Open points are confirmed with the specification’s author before integration. Supports: The rule table on the Türkiye page. Does not show: Regulatory acceptance; the profile is a technical agreement between integrating parties. https://egridium.com/en/evidence#tr-profile-doc
- **Hub portal views per role** (repo-review, Last verified 2026-10-04): The portal route table defines hub-operator views (directory, map, settlement windows, approvals, partners, contract queue, aggregators, operations, stuck work) and partner views (my statements, my records, my contract, roaming, data quality) with CPO-only sharing sets and tariffs and eMSP-only tokens, sessions, reservations and commands. Supports: The portal views listed on the role pages. Does not show: What a given partner sees in production; access is scoped per party. Real screens will be added as separate product-flow records. https://egridium.com/en/evidence#portal-routes-repo
- **Partner sandbox** (repo-review, Last verified 2026-10-04): Sandbox routes in the OCPI adapter and a mock partner and charger simulator let a partner complete the handshake and exercise each module against test data before onboarding. Supports: That a test environment is part of onboarding. Does not show: Self-service sign-up; sandbox credentials are issued after the application is reviewed. https://egridium.com/en/evidence#sandbox-repo

---

# E-Gridium · ChargeBridge (Türkçe)

E-Gridium, şarj ağı işletmecileri ile mobilite hizmet sağlayıcılarının bir kez bağlandığı, kapsamı açıkça belirlediği ve dönem başına uzlaştığı OCPI roaming ve takas hub’ı ChargeBridge’i işletir.

Electroop ve E-Gridium, ortak sahiplik altında faaliyet gösteren ayrı şirketlerdir. ChargeBridge, E-Gridium’un ürünüdür.

Hizmet nerede: Teknik bağlantı katılan partnerler için canlı: el sıkışma, veri akışı ve uzlaştırma ekstreleri. Uzlaştırma, finansal go-live kapısı kapanana kadar (her partnerle veri işleme sözleşmesi, düzenleyici kayıtlar, e-fatura) dry-run çalışır. Bu sitede partner adı veya sayısı yayımlanmaz; bağlı taraflar birbirini hub dizininde görür.

## OCPI modülleri

| Modül | Sürüm | CPO | eMSP | Durum | Kapsam |
| --- | --- | --- | --- | --- | --- |
| credentials | 2.2.1 | Gönderen ve alan | Gönderen ve alan | Sunulur | Token A/B/C değişimi, sürüm uzlaşması ve uç nokta keşfi hub tarafında tamamlanır; gelen ve giden kayıt desteklenir. Tamamlanan el sıkışma tek başına veri akışı açmaz: açıkça kabul edilmiş bir partner ilişkisi gerekir. |
| locations | 2.2.1 | Gönderen | Alan | Sunulur | Tam ve kısmi (PATCH) güncellemeler; paylaşım setleriyle partner başına yayın kapsamı: hangi lokasyonu hangi eMSP’nin göreceğine CPO karar verir. |
| sessions | 2.2.1 | Gönderen | Alan | Sunulur | Durum geçişleri ve şarj dönemleriyle şarjlanma nesneleri; yalnız kabul edilmiş partner ilişkileri boyunca iletilir. |
| cdrs | 2.2.1 | Gönderen | Alan | Sunulur | Tarife ve şarjlanmayla doğrulama, idempotent alım, ardından uzlaştırma penceresine giriş. Türkiye’ye özgü alanlar tr-cdr-additionals ekiyle taşınır. |
| tariffs | 2.2.1 | Gönderen | Alan | Sunulur | Enerji, süre, sabit ve park bileşenleri; partner başına tarife görünürlüğü lokasyonlarla aynı paylaşım kapsamını izler. |
| tokens | 2.2.1 | Alan | Gönderen | Sunulur | Token gönderimi ve gerçek zamanlı yetkilendirme; saklanan token verisi özetlenir ve saklama süresi dolunca silinir. |
| commands | 2.2.1 | Alan | Gönderen | Sunulur | Sahiplik ve görünürlük denetimiyle komut ve asenkron sonuç yönlendirmesi: komut, eMSP o cihazı görmeye yetkiliyse cihaza ulaşır. |
| chargingprofiles | 2.2.1 | Alan | Gönderen | Sunulur | Asenkron sonuçlu profil ayarlama, okuma ve silme; hub iletir, şarj programı hesaplamaz. |
| hubclientinfo | 2.2.1 | Alan | Alan | Sunulur | Rol ve durumla bağlı taraflar dizini; bu web sitesi taraf listesi yayımlamaz. |
| bookings | 2.3.0 | Alan | Gönderen | Sunulur | OCPI 2.3.0 rezervasyon nesneleri kabul edilmiş ilişkiler boyunca iki yönde yönlendirilir. |
| parking | 2.3.0 | Gönderen | Alan | Sunulur | OCPI 2.3.0’da tanımlanan park yeri nitelikleri ve kısıtları; lokasyon yayın kapsamını izler. |
| payment | 2.3.0 | Gönderen | Alan | Sunulur | Hub protokol nesnelerini iletir. Ödeme kuruluşu değildir ve kart sahibi verisi işlemez; para, tarafların kendi ödeme sağlayıcıları arasında hareket eder. |
| tokens (groups) | 2.3.0 | Alan | Gönderen | Sunulur | OCPI 2.3.0’da tanımlanan grup nesneleri; yetkilendirme grubu izler. |
| tr-cdr-additionals | tr-extension | Gönderen | Alan | Sunulur | TRY/kWh birim fiyatı, KDV kırılımı ve iki tarafın raporlama için ihtiyaç duyduğu tanımlayıcılar; CPO tarafından CDR ile birlikte gönderilir. Profil, OCPI-TR özel modül spesifikasyonu olarak ZES tarafından hazırlandı; E-Gridium uygular ve ekosisteme açtığı için ZES’e teşekkür eder. |
| OICP bridge | tr-extension | — | — | Sunulmaz | Kod tabanında bir köprü var ancak hiçbir ortamda kurulu değil. OICP’ye ihtiyaç duyan partnerler o ağa doğrudan bağlanmalıdır. |
| webhooks | tr-extension | — | — | Sunulmaz | Partnerler olayları yukarıdaki OCPI modülleriyle alır; ayrı bir webhook teslim kanalı hizmetin parçası değildir. |

Kaynak: https://egridium.com/tr/ocpi-modulleri

## Şarj ağı işletmecileri için

Lokasyon ve tarifelerinizi bir kez yayımlayın; hangi eMSP’nin hangi sahayı göreceğine partner başına karar verin; şarjlanma, CDR ve uzlaştırma ekstrelerini tek yerden alın.

### Bu roldeki partnerler şunu ister
- Her biri için ayrı entegrasyon olmadan birden fazla eMSP uygulamasının sürücülerine ulaşmak
- Her partnerin hangi saha ve tarifeleri göreceğinin kontrolünü elde tutmak
- Partner partner mutabakat yerine dönem başına netleştirme ekstresi almak
- Türkiye’ye özgü CDR alanlarını özel entegrasyon olmadan taşımak

### Kullandığınız modüller
credentials, locations, tariffs, sessions, cdrs, tokens, commands, chargingprofiles, tr-cdr-additionals, parking-bays

### Neye ihtiyacınız var
- [Teknik kapı] İmzalı roaming katılım sözleşmesi ve veri işleme sözleşmesi
- [Teknik kapı] Unvan, vergi numarası ve varsa şarj ağı işletmeci lisans numarası
- [Teknik kapı] Hub’dan erişilebilen bir OCPI versions ucu ve el sıkışma için Token A
- [Teknik kapı] Lokasyon, tarife, şarjlanma ve CDR için gönderen; token ve komut için alan uygulama
- [Finansal kapı] Her CDR’da tr-cdr-additionals alanlarının doldurulması
- [Finansal kapı] Sözleşmede belirlenen tahsilat ve faturalama bilgileri

### İşin nasıl ilerlediği
1. **Başvuru ve sözleşme** Rolünüz ve versions ucunuzla başvurursunuz; sözleşme ve veri işleme sözleşmesi imzalanır; tarafınız hub dizininde oluşturulur.
2. **Sandbox ve el sıkışma** Kimlik bilgileri önce sandbox ile değişilir; her modül test verisiyle denenir ve eksikler canlıya geçmeden listelenir.
3. **Kapsam ve ilişkiler** Hangi eMSP’lerin hangi paylaşım setini göreceğine karar verirsiniz; her ilişki veri akmadan önce iki tarafça açıkça kabul edilir.
4. **Akış ve ekstreler** Lokasyon, durum ve tarifeler partnerlerinize ulaşır; şarjlanmalar CDR olur; her uzlaştırma penceresi defterle doğrulayabileceğiniz bir netleştirme ekstresiyle kapanır.

### Kapsam bir karardır, varsayılan değil

Paylaşım setleri lokasyonlarınızı gruplar; bir eMSP ile ilişki bir sete işaret eder. Kapsamı daraltmak veya genişletmek tek işlemdir ve her değişiklik denetim defterine yazılır. Hiçbir sette olmayan lokasyon her partnere görünmezdir.

### Hub CDR’larınızla ne yapar

Her CDR tarife ve şarjlanmayla doğrulanır, ardından o partner çifti için açık uzlaştırma penceresine girer. Kapanışta netleştirme ekstresi alırsınız; hub ücreti ayrı satırdır ve roaming tutarlarıyla asla mahsup edilmez. Finansal go-live kapısı kapanana kadar ekstreler dry-run üretilir ve fatura kesilmez.

### Sık sorulan sorular
**Tüm sahalarımı hub’daki her eMSP’ye açmak zorunda mıyım?**

Hayır. Varsayılan kapalıdır. Paylaşım setleri oluşturur ve ilişkileri tek tek kabul edersiniz; hub kabul edilmiş ilişki dışında hiçbir lokasyonu yayımlamaz.

**Şarj yazılımım Electroop’un değil. Yine de bağlanabilir miyim?**

Evet. Hub, uyumlu her uygulamayla OCPI 2.2.1 ve 2.3.0 konuşur. Electroop ürünleri bağlanma yollarından yalnızca biridir; hub, partnerin hangi yazılımı kullandığından bağımsız olarak E-Gridium tarafından işletilir.

**Hangi OCPI sürümünü uygulamalıyım?**

İkisi de olur. Hub sürümü her partnerle ayrı uzlaşır ve nesnelerin farklılaştığı yerde 2.2.1 ile 2.3.0 arasında çevirir; partnerlerinizin sürümü sizin kısıtınız değildir.

**Ücretler nasıl alınır?**

CDR başına yüzde olarak, şarjlanmanın iki tarafı arasında bölünerek, ekstrede kendi satırı olarak. Oran katılım sözleşmesindedir; burada yayımlanmaz.

URL: https://egridium.com/tr/sarj-agi-isletmecileri-icin

## Mobilite hizmet sağlayıcıları için

İlişkiniz olan her CPO’dan lokasyon, canlı durum ve tarifeleri alın; token’larınızı bir kez gönderin; tek komut kanalından başlatın, durdurun ve rezerve edin.

### Bu roldeki partnerler şunu ister
- Her ağı entegre etmeden uygulamada daha fazla cihaz göstermek
- Partner cihazlarında sürücüleri gerçek zamanlı yetkilendirmek
- Tüm CPO partnerleri için dönem başına tek ekstre almak
- Sürücü ilişkisini ve uygulamayı kendi elinizde tutmak

### Kullandığınız modüller
credentials, locations, tariffs, sessions, cdrs, tokens, commands, chargingprofiles, bookings, token-groups, payment-sessions

### Neye ihtiyacınız var
- [Teknik kapı] İmzalı roaming katılım sözleşmesi ve veri işleme sözleşmesi
- [Teknik kapı] Unvan ve vergi numarası
- [Teknik kapı] Hub’dan erişilebilen bir OCPI versions ucu ve el sıkışma için Token A
- [Teknik kapı] Lokasyon, tarife, şarjlanma ve CDR için alan; token ve komut için gönderen uygulama
- [Teknik kapı] Token’lar için gerçek zamanlı yetkilendirme ucu
- [Finansal kapı] Sözleşmede belirlenen tahsilat ve faturalama bilgileri

### İşin nasıl ilerlediği
1. **Başvuru ve sözleşme** Rolünüz ve versions ucunuzla başvurursunuz; sözleşme ve veri işleme sözleşmesi imzalanır; tarafınız hub dizininde oluşturulur.
2. **Sandbox ve el sıkışma** Kimlik bilgileri sandbox ile değişilir; token gönderimi, yetkilendirme ve komut gidiş dönüşü cihaz simülatörüyle denenir.
3. **İlişkiler** Her CPO ilişkisi iki tarafça kabul edilir; o andan itibaren o CPO’nun paylaştığı lokasyon, tarife ve durum size ulaşır.
4. **Şarjlanmalar ve ekstreler** Sürücüleriniz partner sahalarında şarj olur; şarjlanmalar ve CDR’lar hub üzerinden gelir; her uzlaştırma penceresi tüm CPO partnerleriniz için tek ekstreyle kapanır.

### Sahiplik denetimli komutlar

Başlat, durdur, rezerve et veya kilit aç komutu bir cihaza yalnızca o CPO ile ilişkiniz lokasyonu kapsıyorsa yönlendirilir. Sonuçlar asenkron döner ve portal görünümünüzde tam izle görünür.

### Token’lar ve saklama

Hub’a gönderilen token verisi özetlenir; şifreli kimlik bilgileri ve özetler saklama süresi dolar dolmaz silinir. Yetkilendirme kararı sizindir: hub gerçek zamanlı yetkilendirme çağrısını size iletir.

### Sık sorulan sorular
**Hub’daki her CPO’yu otomatik alır mıyım?**

Hayır. İlişkinin hem sizin hem CPO tarafından kabul edilmesi gerekir. Kimin bağlı olduğu hubclientinfo ile keşfedilir; ticari adım sizindir.

**İki rolü birden işletebilir miyim?**

Evet. Bir taraf aynı anda CPO ve eMSP olabilir; hub iki rol bağlamını ve ekstrelerini ayrı tutar.

**Hub bir ödeme kuruluşu mudur?**

Hayır. Hub netleştirme ekstreleri ve ödeme yükümlülükleri üretir; para, sözleşmede belirlenen tahsilat yöntemiyle taraflar arasında hareket eder. Kart verisi hub’dan asla geçmez.

URL: https://egridium.com/tr/mobilite-hizmet-saglayicilari-icin

## Navigasyon ve veri sağlayıcıları için

CPO’ların size yayımlamayı seçtiği lokasyon, durum ve tarifeleri alın; şarjlanma, CDR ve uzlaştırma yok, çünkü ne cihaz işletirsiniz ne de sürücüye satış yaparsınız.

### Bu roldeki partnerler şunu ister
- Harita veya araç ürününde doğru cihaz müsaitliği göstermek
- Ağları tek tek entegre etmek veya kazımak yerine tek akış almak
- Her CPO’nun yayın kararına uymak

### Kullandığınız modüller
credentials, locations, tariffs, hubclientinfo

### Neye ihtiyacınız var
- [Teknik kapı] Veri tüketicisi rolü için imzalı katılım sözleşmesi
- [Teknik kapı] Lokasyon ve tarifeler için yalnız alan OCPI ucu

### İşin nasıl ilerlediği
1. **Başvuru** Veri tüketicisi olarak başvurursunuz; sözleşme aldığınız verinin kullanımını kapsar.
2. **El sıkışma** Alan ucunuza karşı gelen kayıt.
3. **Yayın kararları** Her CPO size yayımlayıp yayımlamayacağına ve neyi yayımlayacağına karar verir; varsayılan hiçbir şeydir.

### Yalnız alıcı

NSP rolünün gönderen modülü yoktur. Şarjlanma, CDR, token ve komutlar veri tüketicisine asla ulaşmaz; uzlaştırma platformu rolün varlığından haberdar değildir.

### Veri kullanımı

Akışla ne yapabileceğiniz protokolde değil sözleşmede belirlenir. Hub kapsamı, siz kullanımı uygularsınız.

### Sık sorulan sorular
**Analitik için geçmiş şarjlanmaları alabilir miyim?**

Hayır. Rol lokasyon ve tarifeler için yalnız alıcıdır; şarjlanma ve CDR verisi şarjlanmanın iki tarafına aittir.

**Durum ne kadar güncel?**

CPO’nun yayımladığı kadar; hub durum güncellemelerini geldikçe iletir, cihazları kendisi sorgulamaz.

**Ücret var mı?**

Veri tüketicileri için ticari koşullar katılım sözleşmesinde belirlenir.

URL: https://egridium.com/tr/katilim-ve-sandbox


## Uyum programları (sertifika değil)

- ISO/IEC 27001:2022: in-progress (hedef 2026-12-31). Hub, ISO/IEC 27001:2022 ile uyumlu bir bilgi güvenliği yönetim sistemi altında işletilir. Denetim hazırlığı kontrol kontrol izlenir; henüz belgelendirme denetimi planlanmamıştır.
- SOC 2 Type II: planning. Güven Hizmeti Kriterleri aynı kontrol setine eşlenmiştir; doğrulama çalışması planlama aşamasındadır.
- PCI DSS SAQ-A: self-assessment. Hub kart sahibi verisi saklamaz, işlemez ve yönlendirmez; partner akışında kartlı ödeme varsa partnerin ödeme sağlayıcısında kalır. SAQ-A kapsam dokümanı hedef mimariyi tarif eder.

## Kanıt kayıtları

- **OCPI 2.2.1 route tablosu** (repo-review, Son doğrulama 2026-10-04): OCPI adaptörü 2.2.1 sürüm ucunun altında credentials, locations, sessions, cdrs, tariffs, tokens, commands, chargingprofiles ve hubclientinfo denetleyicilerini kimlik doğrulama, idempotency, hız sınırı ve denetim ara katmanlarıyla bağlar. Destekler: Dokuz 2.2.1 modülünün hub’da uygulanmış ve yönlendirilmiş olduğunu. Göstermez: Belirli bir partnerin uygulamasıyla birlikte çalışabilirliği; o, partner başına sandbox’ta ve kabul listesinde kurulur. https://egridium.com/tr/kanit#ocpi-221-routes-repo
- **OCPI 2.3.0 route tablosu** (repo-review, Son doğrulama 2026-10-04): Ayrı bir 2.3.0 sürüm ucu rezervasyon, park yeri, ödeme oturumu ve token gruplarını yönlendirir; 2.2.1 ve 2.3.0 partnerleri arasında çeviri katmanı vardır. Destekler: OCPI 2.3.0 nesnelerinin kabul edilip iletildiğini ve karışık sürümlü partnerlerin bağlanabildiğini. Göstermez: Adı verilen bir partnerle 2.3.0’ın üretimde kullanımını; ödeme-oturumu nesneleri hub’ı ödeme kuruluşu yapmaz. https://egridium.com/tr/kanit#ocpi-230-routes-repo
- **Türkiye CDR eki (tr-cdr-additionals)** (repo-review, Son doğrulama 2026-10-04): Ayrı bir denetleyici ve entegrasyon profili her CDR’ın yanında TRY/kWh birim fiyatını, KDV kırılımını ve raporlama tanımlayıcılarını taşır. Temelindeki OCPI-TR özel modül spesifikasyonu (v1.0.0, Ocak 2026) ZES tarafından hazırlandı; E-Gridium yayımlandığı hâliyle uygular ve emek için ZES’e teşekkür eder. Destekler: Türkiye profilinin gönderen ve alan tarafta OCPI eki olarak var olduğunu. Göstermez: Herhangi bir kurumun düzenleyici kabulünü; alanlar tarafların kendi raporlaması için gerekenlerdir. https://egridium.com/tr/kanit#tr-cdr-additionals-repo
- **Uzlaştırma penceresi durum makinesi** (repo-review, Son doğrulama 2026-10-04): Takas platformu her uzlaştırma penceresini OPEN, GRACE_PERIOD, RECONCILING ve CLOSED aşamalarından geçirir; geç gelen CDR’lar ek sürede girer, itirazlar kapanıştan önce görünür. Destekler: Uzlaştırma dönemlerinin, netleştirme ekstrelerinin ve ödeme yükümlülüklerinin platform tarafından üretildiğini. Göstermez: Hub üzerinden partnerler arasında para hareket ettiğini: uzlaştırma, finansal go-live kapısı kapanana kadar dry-run çalışır ve faturalama o zamana kadar çitlidir. https://egridium.com/tr/kanit#settlement-window-repo
- **Hash zincirli uzlaştırma defteri** (repo-review, Son doğrulama 2026-10-04): Defter kayıtları hash ile zincirlenir, bir ekstre girdileriyle yeniden doğrulanabilir; hub ücretleri her taraf için ayrı satır olarak kaydedilir ve roaming tutarlarıyla asla netleştirilmez. Destekler: Defterin kurcalanmaya karşı izlenebilirliğini ve “hub ücreti netleştirme dışında” kuralını. Göstermez: Ücret oranlarını veya paylaşımlarını; onlar katılım sözleşmesindedir, bu sitede değil. https://egridium.com/tr/kanit#ledger-hash-chain-repo
- **Varsayılan kapalı partner ilişkileri** (repo-review, Son doğrulama 2026-10-04): İki taraf arasında açıkça kabul edilmiş, aktif bir partner ilişkisi yoksa hiçbir lokasyon, tarife, şarjlanma, CDR veya token akmaz; yayın kapsamı varsayılan olarak kapalıdır ve değişiklikler denetim defterine yazılır. Destekler: Tamamlanan credentials el sıkışmasının veri akışını açmadığını ve kapsamın açık, denetlenebilir bir karar olduğunu. Göstermez: Sözleşmesel veri paylaşım izinlerini; onlar imzalı sözleşme ve veri işleme sözleşmesinden gelir. https://egridium.com/tr/kanit#edge-fail-closed-repo
- **Token verisi için saklama süresi süpürmesi** (repo-review, Son doğrulama 2026-10-04): Özetlenmiş token verisi ve şifreli kimlik bilgileri saklama süresi dolar dolmaz silinir; süpürme zamanlanmış çalışır ve mevcut en muhafazakâr ayardır. Destekler: Güven sayfasında belirtilen süre dolunca silme kuralını. Göstermez: Veri sorumlusunun kendi saklama yükümlülüklerini; onlar her veri işleme sözleşmesinde belirlenir. https://egridium.com/tr/kanit#kvkk-retention-repo
- **Otomatik test paketi** (test-suite, Son doğrulama 2026-10-04): OCPI adaptörü, takas platformu, kimlik servisi, roaming mesh ve hub portalında yaklaşık 1.500 test dosyası: birim, sözleşme, uçtan uca, özellik tabanlı ve mutasyon testleri. Destekler: Protokol akışlarının ve uzlaştırma mantığının otomatik testlerle kapsandığını. Göstermez: Paketin en son hangi sürümde ve tarihte geçtiğini; tarihli çalıştırma raporu hazır olunca yayımlanacak. https://egridium.com/tr/kanit#test-suite-count
- **OpenAPI tanımları** (document, Son doğrulama 2026-10-04): OCPI adaptörü, takas platformu ve kimlik servisi için makine tarafından okunabilir API tanımları, geliştiriciler sayfasında yayımlanır. Destekler: Bir partnerin entegre olduğu uç nokta yüzeyini. Göstermez: Erişimi: uç noktalar katılım sırasında verilen partner kimlik bilgilerini gerektirir. https://egridium.com/tr/kanit#openapi-specs
- **Uyum programı durumu** (document, Son doğrulama 2026-10-04): ISO/IEC 27001:2022 devam ediyor (boşluk analizi, hedef 2026 sonu), SOC 2 planlamada, PCI DSS SAQ-A öz değerlendirme olarak kapsamlandı; matris her kontrolün durumunu ve sahibini izler. Destekler: Programların var olduğunu ve güven sayfasındaki belirtilen durumlarını. Göstermez: Herhangi bir sertifika veya doğrulamayı: E-Gridium için düzenlenmiş yoktur. https://egridium.com/tr/kanit#compliance-status-json
- **OICP köprüsü kurulu değil** (repo-review, Son doğrulama 2026-10-04): OICP–OCPI köprü servisi her ortamda installed:false işaretlidir ve giden HTTP istemcisi yoktur; lansman karar kaydı onu kapsam dışında tutar. Destekler: Modüller sayfasındaki olumsuz iddiayı: OICP çevirisi sunulmaz. Göstermez: Gelecekteki herhangi bir kullanılabilirliği. https://egridium.com/tr/kanit#oicp-frozen
- **Webhook uçları 501 döner** (repo-review, Son doğrulama 2026-10-04): Yedi webhook ucu 501 Not Implemented döner ve lansman karar kaydıyla genel yol listesinden ve portal menüsünden çıkarılmıştır; teslim zinciri bağlı değildir. Destekler: Modüller sayfasındaki olumsuz iddiayı: webhook sunulmaz. Göstermez: Gelecekteki herhangi bir kullanılabilirliği. https://egridium.com/tr/kanit#webhooks-501
- **Hub’ın mühendislik ayak izi** (repo-review, Son doğrulama 2026-10-04): Tek monorepo’da on iki servis (OCPI adaptörü, takas platformu, kimlik, roaming mesh, PKI, harita verisi, sandbox, operasyon MCP, sahte partner/cihaz ve migrasyonlar), 593 veritabanı migrasyonu, 87 mimari karar kaydı, yaklaşık 1.500 test dosyası ve toplam 83 yol içeren üç OpenAPI dokümanı. Destekler: Hub’ın prototip değil, mühendisliği yapılmış ve belgelenmiş bir sistem olduğunu. Göstermez: Üretim ölçeğini, partner sayısını veya hizmet seviyelerini; sayılar trafiği değil kod tabanını anlatır. https://egridium.com/tr/kanit#engineering-footprint
- **Uzlaştırma mimarisi: sözleşmeler, pencereler, ekstreler, yükümlülükler** (document, Son doğrulama 2026-10-04): İkili, sürümlü sözleşmeler dönemi, ek süreyi, itiraz penceresini, ücret dağılımını, ödeme otomasyonunu ve kur politikasını tanımlar; pencereler OPEN → GRACE_PERIOD → RECONCILING → CLOSED, ekstreler GENERATED → PUBLISHED → ACKNOWLEDGED ilerler ve hub imzalıdır; yükümlülükler borçlu, alacaklı, tutar ve vade taşır. Destekler: Uzlaştırma sayfasında anlatılan yapıyı. Göstermez: Herhangi bir oran, tutar veya gerçek para hareketini; elle mod dışındaki ödeme otomasyonu finansal go-live kapısından sonra partner başına kurulur. https://egridium.com/tr/kanit#settlement-architecture-doc
- **Türkiye profili: tr-cdradditionals’ın bağlayıcı yorumu** (document, Son doğrulama 2026-10-04): Spesifikasyonun boşluk bıraktığı yerlerde hub’ın uyguladığı sekiz kural: birim fiyat anlamı ve hassasiyeti, KDV işleme, sürümlü düzeltme, idempotency yanıtları, version details ile keşif, 24 saatlik uyum açığı raporuyla nihai eşleşme, seri numarası okuma, taşıma güvenliği. Açık noktalar entegrasyondan önce spesifikasyonun yazarıyla teyit edilir. Destekler: Türkiye sayfasındaki kural tablosunu. Göstermez: Düzenleyici kabulü; profil, entegre olan taraflar arasında teknik bir mutabakattır. https://egridium.com/tr/kanit#tr-profile-doc
- **Rol başına hub portal görünümleri** (repo-review, Son doğrulama 2026-10-04): Portal route tablosu hub işletmecisi görünümlerini (dizin, harita, uzlaştırma pencereleri, onaylar, partnerler, sözleşme kuyruğu, toplayıcılar, operasyon, takılan işler) ve partner görünümlerini (ekstrelerim, kayıtlarım, sözleşmem, roaming, veri kalitesi) ile CPO’ya özel paylaşım setleri ve tarifeler, eMSP’ye özel token, şarjlanma, rezervasyon ve komut görünümlerini tanımlar. Destekler: Rol sayfalarında listelenen portal görünümlerini. Göstermez: Belirli bir partnerin üretimde ne gördüğünü; erişim taraf başına kapsamlanır. Gerçek ekranlar ayrı ürün-akışı kayıtları olarak eklenecek. https://egridium.com/tr/kanit#portal-routes-repo
- **Partner sandbox’ı** (repo-review, Son doğrulama 2026-10-04): OCPI adaptöründeki sandbox route’ları ile sahte partner ve cihaz simülatörü, bir partnerin katılımdan önce el sıkışmayı tamamlamasına ve her modülü test verisiyle denemesine izin verir. Destekler: Test ortamının katılımın parçası olduğunu. Göstermez: Self-servis kaydı; sandbox kimlik bilgileri başvuru incelendikten sonra verilir. https://egridium.com/tr/kanit#sandbox-repo