Quickstart

Receiving setup and verification

Confirm your email and submit your business details. Ulasend reviews every new application before enabling payment processing. You can use the dashboard while review is pending, but you cannot collect payments yet. An administrator approves your application and chooses a shared receiving wallet or your business's own Bridge wallet.

The new application review requirement does not interrupt existing active merchants. Their current receiving setup stays in place unless Ulasend changes it or places the account on hold.

Shared receiving can begin after administrator approval and the selected wallet's readiness checks pass. Your orders and balance remain tracked separately. Choosing your own wallet keeps payments paused until your verification and wallet setup are complete and Ulasend resumes checkouts. Adding a payout wallet never changes where customer payments are received.

Only a Ulasend administrator can start your business and owner verification when preparing your account for its own receiving wallet. Until then, the verification page shows that you are awaiting Ulasend authorization. Eligible shared-wallet USDC payouts on Base use separate account, destination, and available-balance checks. Other payout routes require your own approved verification and all remaining payout checks. Completing verification does not switch receiving automatically; Ulasend makes that change manually.

When Ulasend starts verification, it makes the form available in your portal and queues an invitation to your verified contact. Email delivery can be delayed; open Verification directly to check your next steps. Additional information requests and available reference links appear there. Bridge or Persona may also contact you separately.

See Wallet setup and verification for receiving options, payout wallet review, and the requirements for cashout. ACH requires your business's own eligible receiving wallet; shared receiving wallets do not support ACH.

1. Get an API key

In the Ulasend dashboard, create a test key (pk_test_…). Store it as an environment variable on your server - never in frontend code:

export ULASEND_API_KEY="pk_test_xxxxxxxx"

2. Create an invoice for this order

Call Ulasend from your backend when the buyer is ready to pay. Pass this cart's dollar total as usd_amount:

curl -X POST https://ulasend.com/api/v1/invoices \
  -H "Authorization: Bearer $ULASEND_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-12345" \
  -d '{
    "usd_amount": "49.99",
    "asset": "USDC_BASE",
    "customer_email": "buyer@example.com",
    "external_reference": "order-12345"
  }'

3. Send the buyer to checkout

Redirect them to checkout_url in the response. The test-key example above opens a simulation without real payment controls. After switching to an authorized live key, a USDC on Base checkout can accept a wallet payment or offer card-funded crypto when available. Choose the source before creating a live invoice; its instructions cannot switch to another coin or network. Configure accepted methods under Settings → Payment methods. See Supported payment methods for other crypto sources and eligible bank transfers.

4. Fulfill on the webhook

Verify the signature on invoice.paid, then match the invoice and order reference, confirm the current status and actual received amount, and fulfill once. Use test events only for test orders; a real order requires live payment evidence. A browser return or bank transfer submission is not proof of payment. Follow the webhook fulfillment checks.