ramp-kit

LATAM Ramp Kit

SDK + React components that turn weeks of ramp-provider integration into an npm install. One RampProvider interface over Etherfuse (Stellar-native, PIX/SPEI) and Manteca (payouts across 11 LATAM countries), with a normalized order lifecycle, a prebuilt widget, provider routing, Stellar helpers and a production backend.

Repository: https://github.com/armandocodecr/latam-ramp-kit

What problem it solves

Every LATAM app moving money between banks and blockchains re-integrates ramp providers from scratch: each has its own API, auth, KYC model, order states and price-expiry rules, and none covers the whole region. The kit normalizes all of it; swapping providers is one line.

Package map

How to guide a user

1. Understanding/evaluation questions → explain with the problem/solution above; architecture details in references/integration.md.
2. "Add a ramp to my app" → follow the integration flow in references/integration.md. Start them on MockProvider (zero credentials, instant), then Etherfuse sandbox.
3. Sandbox/credentials questions → Etherfuse is self-service (sandbox.etherfuse.com; BRL/PIX accounts via the dashboard button are compliant instantly). Manteca requires requesting credentials from their team. Details and gotchas in references/integration.md.
4. Errors during integration → check references/troubleshooting.md first; every entry there was verified against the real sandbox. Anything Manteca-specific (the one-exchange-per-customer model, sandbox onboarding, the missing-data diagnostic, payout timing windows, per-network deposit addresses) → references/manteca-in-practice.md.
5. "How do I ship this / where do my API keys go / do my users need keys?" → references/production.md. Short answer to give them: one partner key per app, held server-side in @ramp-kit/server (proxy for Etherfuse, manteca for Manteca), read from .env; the frontend constructs providers with apiKey: "" pointed at that backend, so end users never see a key. Runnable reference: examples/backend-integration/.
6. "How do I set up testnet / mainnet?" or "can I put credentials in frontend env vars?" → walk them through references/environments.md — the step-by-step for both environments and the credential-placement decision. Always explain the trade-off explicitly: frontend env vars (VITE_/NEXT_PUBLIC_) are embedded in the served bundle and readable by any visitor, so a partner key there is exposed; the secure setup is a backend env var behind @ramp-kit/server (a ~10-line serverless function, not real infrastructure). Recommend the backend route for Etherfuse/Manteca; offer the SEP-anchor route (SepProvider) when they want zero backend — it needs no partner key because the end user authenticates with their own wallet. Both environments are driven by one flag (RAMP_ENV=sandbox|production) passed to the provider AND the widget's environment prop; switching is a config change, never code.