Alexei Rojas Quiroga
enes
← All projects

Corporate project · Presented company-agnostic: architecture and decisions only.

Crypto Payments Platform

Distributed platform for merchants to accept payments in any cryptocurrency

Status
In production
Role
Backend engineer: microservices, messaging, real-time notifications

Architecture

  • Bitcoin · Ethereum · Litecoin
  • RabbitMQ message bus
  • SQL Server persistence
  • Dead-letter handling

The merchant client submits a payment request; the API validates and stores it as pending, then enqueues it and acknowledges immediately.

Architecture · 9 nodes · 2 flows
WHAT I BUILTMerchant checkoutSends requests,receives resultsASP.NET CorePayment intakeValidates and acceptsrequestsRabbitMQRequest queueBuffers paymentrequests.NET workerPayment executorExecutes payments on-chainBTC/ETH/LTCCoin adaptersOne adapter per coinRPC per coinBlockchain nodesNetwork for eachsupported coinRabbitMQDead-letter queueFailed messages forreviewUser walletFunds and signingSQL ServerPayments storePayments and statushistory123
  • Service / compute
  • Data store
  • Queue / messaging
  • Client
  • External system
  • Synchronous
  • Async / loop
Scroll sideways to see the full diagram

How it flows, step by step

Click a step to jump to it. Click a component for details.

What it does

A distributed payments platform that any merchant could integrate to accept payments in Bitcoin, Ethereum, Litecoin and other cryptocurrencies. Microservices on C#/.NET communicate through RabbitMQ: one receives and enqueues payment requests, another executes the payment on-chain with the user's wallet, and a third waits for confirmation and pushes the result to the client in real time through SignalR. State lives in SQL Server.

The problem

Merchants wanted to accept cryptocurrency without building blockchain integrations themselves, yet on-chain payments are slow to confirm and can fail. The platform had to accept requests reliably, execute them safely, and tell clients the outcome as soon as it was final.

What I built

  • Microservices decoupled by RabbitMQ: request intake, on-chain execution, confirmation tracking and notification scale and fail independently.
  • Payment API accepts and enqueues requests quickly, so merchants get an immediate acknowledgement while heavy work happens asynchronously.
  • Idempotent message processing so redelivered messages never submit the same payment twice.
  • Execution separated from confirmation: a Confirmation Watcher tracks blockchain finality, which can take minutes, without blocking the executor.
  • Real-time results pushed to clients through a SignalR hub instead of client polling.
  • Coin adapters give Bitcoin, Ethereum and Litecoin a common execution contract, and every payment state transition is persisted in SQL Server.

Key decisions and why

01

RabbitMQ as the bus between microservices

Queues absorb bursts, let each service scale on its own and keep accepted requests safe if a downstream service is down; failed messages go to a dead-letter queue for inspection.

02

Idempotent processing

Messaging is at-least-once, so each payment carries a unique key and handlers check persisted state before acting, preventing duplicate on-chain transactions.

03

Separate execution from confirmation

Broadcasting a transaction is quick but finality is slow and variable per chain. A dedicated watcher polls for confirmations and emits an event, so executors stay free.

04

SignalR push instead of polling

Clients learn the outcome the moment the confirmation event arrives, with less load and lower latency than repeated status requests.

05

SQL Server as the system of record

Payment state and its history are relational and transactional, which makes recovery, reconciliation and auditing straightforward.

Tech stack

Languages
C#
Backend
.NETASP.NET CoreSignalR
Messaging
RabbitMQ
Data
SQL Server
Other
Bitcoin, Ethereum, Litecoin nodes (RPC)