Store Credit

(store-credit)
30-day money back guarantee

30-day money back guarantee

Turn refunds into repeat purchases with a financial-grade Store Credit system for Magento 2 & Mage-OS. Built for modern commerce teams, qoliber Store Credit delivers atomic balance operations, double-spend protection, Hyvä & headless support, multi-currency handling, REST & GraphQL APIs, and enterprise-grade reliability for high-scale stores.
SKU store-credit

Gitlab access is only given to Agencies and Freelancers after
approval process.

Please note: we do not provide installation or implementation services for our extensions.

Installation should be handled by the developer or agency managing your store. This approach ensures:

  • Compatibility with your current setup
  • Proper configuration based on your specific version
  • Implementation by someone familiar with your codebase

Although we don’t offer installation, we maintain a curated list of recommended development agencies experienced with our solutions.

If you'd like to receive this list, please contact us at [email protected].

Partnership Inquiries

Store Credit — qoliber
QOLIBER · STORE CREDIT

Financial-grade store credit infrastructure for Magento 2 & Mage-OS.

Important Licensing & Integration Information

One license = one e-commerce project instance. Multi-store deployments under a single project are covered; additional project instances require additional licenses. Source is published and reviewable on the github.com/qoliber organization — commercial use requires a purchased license key.

Store Credit is a financial-grade store credit infrastructure designed for agencies, solution architects, and merchants who need correctness, scalability, and long-term maintainability. Built around an append-only ledger with reserve / capture flows and atomic balance operations, the module handles refunds, customer balances, multi-currency credits, and headless storefronts without compromising performance or financial integrity.

Works with   Magento Open Source · Adobe Commerce · Mage-OS · Hyvä Themes · Hyvä Checkout · PHP 8.1 – 8.5
01 Append-only ledger 02 Reserve → Capture 03 Multi-currency 04 REST + GraphQL 05 Hyvä native 06 Migration included
Why agencies buy Store Credit

Store credit looks trivial until refunds, partial captures, and concurrent sessions hit production. We treat balances as a ledger, not a number — the operational risk you'd otherwise discover months later is engineered out at install time.

The module ships as a repeatable primitive: one installation pattern, the same reconciliation tools, the same upgrade path across every project. Agency teams stop writing custom financial logic per client and start reusing infrastructure with a reviewable surface.

Security hardening, race-condition handling, and replay safety are done upstream so the team shipping the storefront focuses on the storefront — not on rebuilding a credit primitive every quarter.

Store Credit Summary
v1.0.0

Append-only ledger. Reserve, capture, refund — atomically.

Architecture
Append-only
ledger + locks
PHP runtime
8.1 → 8.5
PHPStan L8
APIs
REST · GraphQL
stable @api
Hyvä
Native
Magewire incl.
What you get (technical scope)
  • › Append-only store_credit_ledger with running balance projection
  • › Reserve → capture state machine with idempotency keys
  • › Row-level locking against concurrent balance mutation
  • › Atomic refund-to-credit with over-refund caps
  • › Fixed FX rate snapshot per transaction, per currency
  • › Retry queue + bin/magento qoliber:store-credit:repair
  • › Reconciliation service + /health/store-credit endpoint
  • › Swappable strategy interfaces & stable service contracts
  • › Migration importer for legacy store credit balances
Why this exists

A store credit primitive is too small to justify a four-week build per project, and too financial to leave undocumented. Store Credit collapses that recurring cost into a single, reviewable module and removes the long-tail of reconciliation tickets from the agency's backlog.

admin / customers / 4821 · store credit ledger EUR
Available balance
€ 142.40
Reserved
€ 18.00
seqoprefΔ amountbalance
0007 reserve order#100000247 −€ 18.00 € 142.40
0006 capture invoice#000000183 −€ 45.00 € 160.40
0005 refund creditmemo#000091 +€ 32.00 € 205.40
0004 fx_snapshot USD → EUR @ 0.928 — € 173.40
0003 grant admin/loyalty +€ 50.00 € 173.40
0002 capture invoice#000000172 −€ 27.60 € 123.40
0001 open migration:legacy_credit +€ 151.00 € 151.00
append-only · row-locked · idempotent ✓ reconciled
Free Migration Included

Bring every balance across. We handle the import.

Already running Magento store credit from another vendor — or the legacy Adobe Commerce module? The migration importer is included at no extra cost. Balances, transaction history, and customer references move into the append-only ledger with full provenance, no manual SQL, and zero customer disruption.

$ bin/magento qoliber:store-credit:migrate --from=<vendor> --dry-run
01

Balances preserved

Every customer's current available balance is imported 1:1, including reserved and pending amounts where the source schema exposes them.

02

Transaction history

Historical credits, debits, refunds, and admin adjustments are replayed as append-only ledger entries with original timestamps and references.

03

Dry-run & reconcile

The importer runs against a copy of production first, emits a drift report, and only commits after reconcile reports zero variance.

04

Zero customer disruption

Cutover happens inside one maintenance window. Customers never see a missing balance, a duplicate refund, or a credit that silently changes value.

Supported sources: Adobe Commerce store credit Amasty Mageplaza Mirasvit + custom on request
Features

Twelve capabilities that ship in the box.

Every capability below maps to a concrete service, table, or CLI command in the module — not a marketing bullet. Each was added because we hit it in production on a Magento project.

01

Financial-grade ledger

Store credit is handled through an append-only ledger with reservation and capture flows instead of simple balance subtraction. Every operation is auditable and traceable.

02

Double-spend protection

Database row locking prevents concurrent balance usage across multiple tabs, devices, or sessions. Credit cannot be spent twice.

03

Atomic refund workflows

Refund-to-credit operations are atomic, replay-safe, and capped against over-refunding scenarios to eliminate balance inconsistencies.

04

Built for agencies

Deploy repeatable, production-ready credit infrastructure across multiple Magento projects without building custom financial logic for every client.

05

Multi-currency ready

Fixed FX rates captured at transaction time ensure stable reconciliation across currencies and international storefronts.

06

REST & GraphQL APIs

Complete REST and GraphQL coverage enables headless storefronts, PWA projects, Hyvä integrations, and custom checkout implementations.

07

Hyvä & headless native

Dedicated Hyvä Checkout support with native Magewire components plus API-first architecture for modern commerce builds.

08

Self-healing operations

Automatic retry queues and repair CLI commands recover failed capture and refund operations without manual intervention.

09

Reconciliation & health checks

Built-in verification, rebuild tools, reconciliation services, and health endpoints simplify production monitoring and operational support.

10

Extensible architecture

Swappable strategy interfaces and stable service contracts allow developers to extend core behaviors without rewriting business logic.

11

Enterprise code quality

Built with PSR-12, Magento coding standards, PHPStan Level 8 and extensive automated testing for long-term upgrade stability.

12

Migration included

Free migration from existing Magento store credit solutions including balances and transaction history with zero customer disruption.

Why agencies choose

Operational primitives, not a feature gallery.

The cost of store credit isn't visible in the demo. It shows up in the third refund of a multi-currency order, in the customer who opened two tabs, in the upgrade six months from now. Store Credit is engineered for what happens after launch.

~/project · zsh php 8.3
$ composer require qoliber/module-store-credit ^1.0
→ resolved · 0 conflicts · 1 package added
$ bin/magento setup:upgrade
→ schema: store_credit_ledger created · indexes ok
› bin/magento qoliber:store-credit:verify
  â†’ scanned 14,802 entries · drift: 0.00 · locks: 0 stale
› bin/magento qoliber:store-credit:reconcile --since=30d
  â†’ reserved: 412 · captured: 388 · refunded: 24 · open: 0
✓ store credit healthy — ready for traffic
  1. 01
    Append-only ledger instead of mutable balance fields.
    Every state change becomes an entry. Bugs become reviewable instead of catastrophic.
  2. 02
    Reserve → capture workflows prevent financial inconsistencies.
    Two-phase movement of funds eliminates the "credit applied, order not placed" failure mode.
  3. 03
    Headless-ready APIs simplify PWA and custom checkout builds.
    REST + GraphQL parity, no admin-only endpoints — checkouts are not second-class citizens.
  4. 04
    Stable @api contracts reduce upgrade risk.
    Service interfaces follow Magento's API stability rules. Minor versions don't break your patches.
  5. 05
    Recovery tooling and reconciliation are part of the platform.
    Repair CLI, retry queue, drift detection — the tickets that wake an on-call dev are handled upstream.
  6. 06
    Hyvä-native implementation without storefront compromises.
    Magewire components ship in the package — no Knockout fallbacks, no jQuery glue, no rewrites.
How it compares

Store Credit vs. a typical 3rd-party module.

Compared category-by-category against what is commonly shipped in Magento store credit extensions. The comparison reflects defaults, not what can be retrofitted with custom development.

Capability
Store Credit
Typical 3rd-party
Financial model
Append-only ledger, projected balance
Mutable balance field on customer
Double-spend prevention
Row-level DB locking per balance
Rarely addressed
Reserve / capture lifecycle
Two-phase, idempotent, expirable
Single-step debit
Refund integrity
Atomic, replay-safe, over-refund cap
Basic refund workflow
Multi-currency
FX rate snapshot per transaction
Base currency only
Headless support
Full REST & GraphQL parity
Often partial or missing
Hyvä compatibility
Native Magewire components
Varies by vendor
Recovery tooling
Retry queue + repair CLI
Manual recovery
Reconciliation
Drift detection + /health endpoint
Not provided
Extensibility
Swappable strategy interfaces, stable @api
Plugin/preference overrides only
Code standards
PSR-12, PHPStan L8, automated tests
Usually undocumented
Migration path
Free importer, balances + history
Re-grant or manual SQL
Upgrade stability
Versioned @api contracts
Tied to internal classes

Comparison reflects common defaults across publicly available Magento store credit extensions as of 2025. Individual third-party vendors may address specific gaps; the table compares out-of-the-box behavior, not custom-built variants.

Compatibility matrix

What's tested, what's legacy.

Production status is reserved for stacks we run in CI and verify on every release. Legacy stacks remain supported on request — backported for active customers, not maintained by default.

Stack
Version
Status
Notes
Magento Open Source
2.4.6 – 2.4.8
Production
CI matrix · primary target
Adobe Commerce
2.4.6 – 2.4.8
Production
B2B modules verified
Mage-OS
1.0+
Production
Tracks Mage-OS release cadence
Hyvä Themes
1.3+
Production
Magewire components shipped
Hyvä Checkout
1.2+
Production
Native payment-row integration
PHP runtime
8.1 · 8.2 · 8.3 · 8.4
Production
Full CI matrix
PHP runtime
8.5
Production
Tracked from RC; smoke + static analysis
Legacy Magento
2.3.x – 2.4.5
Legacy
Backports on request, scoped per project