Blockchain & Pasarela de Pago — Overview

Contexto — recuerden lo que dice el TPC

Recuerden que el core de la asignatura es el desarrollo de un sistema informático, y que independientemente del dominio o tipo de sistema que propongan (e-commerce, plataforma de servicios, marketplace, sistema de reservas, etc.), todos los proyectos deberán incorporar obligatoriamente una pasarela de pago como parte de su arquitectura.

La pasarela debe contemplar el registro y validación de transacciones usando blockchain real, en testnet y modelar correctamente: la conexión entre pagador y receptor, la gestión de transacciones, la confirmación del pago y el registro inmutable de la operación.

El MVP funcional con la red de pagos basada en blockchain representa el 70 % del criterio de evaluación técnica del trabajo.

Estas 4 clases son el camino corto y técnico para llegar ahí: integrar pagos reales en Sepolia (testnet de Ethereum) en su proyecto, sin importar si eligieron VibeCheck, DepFund, RNW o IDEAFY — o cualquier otro dominio.

Analogía rápida: lo que vamos a hacer es igual a integrar MercadoPago en una app — solo que el rail de pago es la blockchain de Ethereum (testnet Sepolia), y el “saldo” del usuario son tokens USDC en su wallet, no pesos en MP.

Cómo se conecta con lo que ya saben

Web3 NO reemplaza Web2 — augmenta. Su backend Node/Python sigue ahí, su frontend sigue ahí, su observabilidad sigue ahí. Lo que se reemplaza es solo:

• MercadoPago → contrato PaymentGateway.sol en Sepolia.
• Auth con email+password → firma criptográfica de wallet (SIWE).
• Base de datos para estado crítico (ownership de tokens, balances) → storage on-chain del contrato.

Roadmap (4 clases × ~4 hs)

Diagramas hero

Estos 5 diagramas cubren todo el modelo mental. El orden va de zoom-out → zoom-in → tactical.

1 · El ciclo de un smart contract

Del archivo .sol que escribís, al contrato deployado, al usuario final que lo usa desde el browser. Tres swim-lanes: tu máquina (donde escribís el código), blockchain (donde vive el contrato), Etherscan (la UI pública del contrato).

2 · Las 3 capas — mapa global del sistema

El mapa mental de más alto nivel: edge / cliente (browser + wallet del usuario, frontend en Vercel) · web2 infra en k3s (backend, indexer, Postgres, IPFS, Loki/Grafana — todo lo que NO es blockchain) · on-chain en Sepolia (contrato + USDC + state inmutable). Todo lo que ya saben de TP0 (k3s) y TP2 (observabilidad) paga acá, en la capa del medio.

Regla práctica: si lo pueden romper sin pedirle permiso a nadie → es suyo (k3s o Vercel). Si necesitan firma + gas → es on-chain.

3 · Pasarela de pago — el corazón del TP

Dos caminos:

• A — Crypto-nativo: el usuario ya tiene USDC. Conecta wallet → approve → pay. Su contrato cobra y emite evento.
• B — Fiat onramp: el usuario llega con tarjeta/MercadoPago/transferencia. Un provider (Lemon, Buenbit, MoonPay) convierte ARS → USDC y deposita en su wallet. Después sigue por camino A.

Insight clave: el contrato siempre cobra en crypto (USDC). El onramp es solo UX para usuarios sin wallet con fondos. La lógica del contrato no cambia entre los dos caminos.

4 · Read vs Write — la distinción crítica

cast call (lectura, gratis, instantánea) vs cast send (escritura, firma + gas, espera bloque). Misma sintaxis en Solidity, comportamiento radicalmente distinto.

Regla mnemotécnica: si la función dice view o pure → cast call. Cualquier otra cosa → cast send.

5 · Qué vive dónde — público vs privado

Mapa de qué se puede compartir y qué nunca. Lo rojo (private key, frase BIP-39, .env) nunca sale de su máquina. Lo verde (address, txs, bytecode, storage) es público por diseño — toda la blockchain es leíble por cualquiera.

El contrato base que se llevan

Después de la clase 2 todos tienen este patrón en la mano:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import {ReentrancyGuard} from "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract PaymentGateway is ReentrancyGuard {
    IERC20 public immutable usdc;
    address public immutable treasury;

    event Paid(address indexed payer, uint256 amount, bytes32 indexed action);

    constructor(IERC20 _usdc, address _treasury) {
        usdc = _usdc;
        treasury = _treasury;
    }

    function pay(uint256 amount, bytes32 action) external nonReentrant {
        require(amount > 0, "amount=0");
        require(usdc.transferFrom(msg.sender, treasury, amount), "transfer failed");
        emit Paid(msg.sender, amount, action);
        _onPaid(msg.sender, amount, action);
    }

    /// @dev Cada proyecto sobrescribe esto con su lógica:
    ///   - VibeCheck: mintea ticket NFT
    ///   - DepFund: emite shares de $DPF
    ///   - RNW: registra como inversor
    ///   - IDEAFY: rutea al sub-token del proyecto
    function _onPaid(address payer, uint256 amount, bytes32 action) internal virtual {}
}

La pasarela es la misma. Lo que cambia es qué pasa adentro de _onPaid. Cada equipo escribe su propia subclass.

Stack obligatorio para el TP final

Material relacionado

• Clase 1 — Fundamentos + setup + tu primer contrato
• Clase 2 — ERC-20 + PaymentGateway + Reentrancy
• Clase 3 — Frontend + integración + onramp testnet
• Clase 4 — NFTs gamificados + tokenomics + Slither
• TP 0 — Kubernetes
• TP 1 — Selenium MercadoLibre
• TP 2 — Observabilidad