Phileas Fog is an online art commerce platform that helps customers discover and purchase artwork through a digital storefront. As the platform grew, legacy systems made localization, payment processing, inventory management, and order security harder to maintain. The modernization initiative focused on creating a more scalable, secure, and reliable e-commerce experience without a complete platform rewrite.
Legacy commerce platforms tend to accumulate risk in exactly the places that matter most to revenue. Translation, checkout, payment, order, and stock changes had each been built as separate implementation details rather than one connected business workflow, and client-side actions carried responsibility that belonged on the server. Content operations were release-dependent, while payment events could arrive late or more than once.
Most translated interface copy lived in hardcoded i18n files. When administrators added or changed storefront content, new language variants could not be managed dynamically from the admin panel, so even a small content update could require developer involvement and a further application release before customers saw it.
Checkout could clear or reduce stock before the customer completed payment, so a cancelled or abandoned attempt made artwork look unavailable although no sale had occurred. Payment status could also sit pending and later succeed, leaving stock blocked, released too early, or inconsistent with the final outcome.
Modernization was delivered capability by capability rather than as a high-risk rewrite. The team strengthened the boundaries where legacy behavior created the greatest revenue or operational exposure, keeping payment, order, inventory, and authorization decisions on the server. High-risk logic was separated into clear localization, payment, order, inventory, authorization, and reconciliation responsibilities.
Existing i18n files continued to serve stable interface copy, while a new dynamic translation layer handled content created through the admin panel. Administrators could enter localized values for every supported language, and the storefront resolved the right value with fallback behavior when a customer switched language.
Checkout was reorganized so a client request could start a payment but never declare it successful. The server verified the outcome with the provider, validated the current order state, and applied fulfillment or inventory changes only through an approved transition, with repeated callbacks handled idempotently.
Administrators could publish localized dynamic content straight from the admin panel, rather than waiting on a translation-file change and a full application deployment to reach customers.
Stock was tied to an explicit reservation and payment lifecycle, so failed, abandoned, or expired attempts returned inventory without ever clearing a valid and successfully paid order.
Server verification, controlled state transitions, locking, and idempotency reduced the chance of duplicate completion, overselling, or orders that disagreed with the recorded payment status.
Eternalight modernized Phileas Fog capability by capability rather than through a rewrite. i18n and an admin-managed CMS handle localization, a payment gateway with webhooks keeps payment truth on the server, and ACID transactions, row-level locking, idempotency keys, and TTL expiry protect limited stock. Delivery followed a structured process from brainstorming and wireframes through development, integration, launch, and user feedback.
Brainstorming
Wireframe
Development
Send us a message, and we’ll promptly discuss your project with you.
There was no reliable transaction or order-locking strategy around limited inventory. Two overlapping checkout attempts, a duplicated payment callback, or a repeated request could compete for the same artwork and leave the order and stock records inconsistent, partially written, or processed more than once.
The legacy flow lacked a strong server-side order authority boundary. Sensitive actions needed consistent ownership, role, and order-state validation so that one customer, or any client-controlled request, could not read, alter, pay for, cancel, or complete an order that fell outside its permitted scope.
Order creation and stock reservation moved behind database transaction and locking guards, so availability, reservation, and order state changed as one controlled operation. Each reservation carried an expiry, and a scheduled sweeper released stock only after confirming the order had not been successfully paid.
A single authorization layer validated the authenticated user, order ownership, administrative role, permitted action, and current order state before any sensitive operation ran. Client-provided identifiers were treated as lookup inputs rather than proof of authority, across checkout, payment, and admin flows.
User Feedback
Launch
Integration
Multilingual content management.
Dynamic content publishing.
Secure payment processing and verification.
Platform integrations and data exchange.
Role-based access and authorization.
Scheduled tasks and workflow automation.
Automated event-based communication.
