> ## Documentation Index
> Fetch the complete documentation index at: https://ramps-09-18-screening-unavailable-500.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Implementation Overview

> High-level implementation plan for configuring, onboarding, funding, and moving money

This page gives you a 10,000‑ft view of an end‑to‑end implementation. It is intentionally generalized because the flow supports multiple customer types and external account types (e.g., `USD_ACCOUNT`, `EUR_ACCOUNT`, `MXN_ACCOUNT`, `INR_ACCOUNT`). The detailed guides that follow provide concrete fields, edge cases, and step‑by‑step instructions.

## Platform configuration

Configure your platform once before building user flows.

* Set your UMA domain and brand details used for UMA addressing
* Configure required counterparty and compliance fields for your target corridors
* Provide webhook endpoints for outgoing and incoming payment notifications
* Generate API credentials for Sandbox (and later Production)
* Review regional capabilities (rails, currencies, settlement windows)

## Customer creation and onboarding

Onboard customers and assign UMA addresses if appropriate. There are two patterns:

* Regulated entities can directly create customers by providing KYC/KYB data via API
* Unregulated entities should request a KYC link and embed the hosted KYC flow; once completed, the customer can transact
* Store platform customer IDs and UMA handles for use in payment flows

## Account funding

Choose how transactions are funded based on your product design and region.

* Prefunded: Maintain balances in one or more currencies and spend from those balances
* Just‑in‑time (JIT): Create a quote and fund it in real time using the payment instructions provided; ideal when you don’t wish to hold float

<Tip>
  You can mix models: keep small operational float for common corridors and use JIT for long tail routes.
</Tip>

## External account creation (payout destinations)

Register payout accounts your customers will send to (or receive from), such as CLABE (MX), IBAN (EU/UK), US accounts, UPI (IN), and others.

* Capture beneficiary details (individual or business) and required banking fields
* Validate account formats where applicable and map them to your internal customer

## Sending payments

Sending consists of lookup, pricing, funding, and execution.

* Resolve the counterparty: look up receiver information (UMA or bank account) for compliance review and to determine capabilities
* Create a quote: specify source/destination, currencies, and whether you lock sending or receiving amount; receive exchange rate, limits, fees, and (for JIT) funding instructions
* Fund and execute: for prefunded, confirm/execute; for JIT, push funds exactly as instructed (amount, reference) and the platform handles FX and delivery
* Observe status via webhooks and surface outcomes in your UI

<Note>
  When sending UMA payments, the sender can retrieve counterparty information before initiating to support compliance and risk checks.
</Note>

## Receiving payments

Enable customers to receive funds to their UMA or linked bank account.

* Expose customer UMA/addressing to payers
* The platform handles conversion and offramping to the receiver’s account currency
* Approve or auto‑approve per your policy; update balances on completion via webhooks

## Reconciling transactions

Implement operational processes to keep your ledger in sync.

* Process webhooks idempotently; map statuses (pending, processing, completed, failed)
* Tie transactions back to quotes and customers; persist references
* Produce statements and audit trails; handle refunds, retries, and dispute flows where applicable

## Testing in Sandbox

Use Sandbox to build and validate end‑to‑end without moving real funds.

* Exercise receiver lookup, quote creation, funding instructions, and webhook lifecycles
* Validate compliance decisioning with realistic but synthetic data
* Optionally use the Test Wallet as a counterparty for faster iteration (see Tools)

## Enabling Production

When you’re ready to go live:

* Complete corridor and provider onboarding as needed for your regions
* Confirm webhook security, monitoring, and alerting are in place
* Review rate limits, error handling, retries, and idempotency keys
* Run final UAT in Sandbox, then request Production access from your Lightspark contact

<Check>
  Contact your Lightspark representative to enable Production and finalize corridor activations.
</Check>

## Support

If you need assistance with the Grid API, please contact our support team
at [support@lightspark.com](mailto:support@lightspark.com) or visit our support
portal at [https://support.lightspark.com](https://support.lightspark.com).