---
updatedAt: 2026-07-25T19:20:52.000Z
agentTools:
  projectIndex: https://docs.honeycoin.app/llms.txt
---

# Testing Offramps

In Test/Sandbox environment, use the following test accounts to simulate different offramp scenarios. All test transactions must use chain: BASE.

# ✅ Successful Transactions

## Successful Bank Account Offramp

**Account Details:**

* **Account Number:** `1234567890`
* **Bank Code:** `Any code`
* **Account Name:** `Any name`
* **Destination:** Bank Account
* **Currency:** USDC → KES

**Example:**

```json
"payoutMethod": {
  "accountName": "Test User",
  "accountNumber": "1234567890",
  "code": "07"
}
```

***

## Successful Mobile Money Offramp

**Account Details:**

* **Phone Number:** `254712345678`
* **Account Name:** `Any name`
* **Destination:** MoMo
* **Currency:** USDC → KES

**Example:**

```json
"payoutMethod": {
  "accountName": "Test User",
  "accountNumber": "254712345678"
}
```

***

# ❌ Failed Transactions

The failure fixtures below simulate a failed off-ramp status and webhook. They do not receive real crypto, do not set a deposit `txId`, and do not create an on-chain `refundTransactionHash`.

Use them to test your failed-payout handling. Do not send real crypto to a sandbox deposit address. In production, an automatic refund is attempted only when Honeycoin has detected the crypto deposit and the failed off-ramp has a `txId`.

## Failed Bank Account

**Account Details:**

* **Account Number:** `0987654321`
* **Code:** `Any code`
* **Currency:** USDC → KES

***

## Failed Mobile Money

**Account Details:**

* **Account Number:** `254787654321`
* **Currency:** USDC → KES

***

# 🔍 Test Scenarios Reference

| Scenario                 | Destination  | Account Number | Bank Code | Expected Result |
| ------------------------ | ------------ | -------------- | --------- | --------------- |
| Successful Bank Transfer | Bank Account | 1234567890     | any       | ✅ Success       |
| Successful Mobile Money  | MoMo         | 254712345678   | N/A       | ✅ Success       |
| Failed Bank Account      | Bank Account | 0987654321     | any       | ❌ Failed        |
| Failed Mobile Money      | MoMo         | 254787654321   | N/A       | ❌ Failed        |

***

# ↩️ Test Refund Reconciliation

For production-compatible integration logic, model the refund as two separate observations:

1. Receive a `transaction_updated` webhook with `status: "failed"`, `type: "offramp"`, and a deposit `txId`. This confirms the payout failed, not that the refund completed.
2. Query `GET /api/b2b/transactions/{transactionId}` and mark the refund complete only when the original off-ramp includes `refundTransactionHash`. Escalate to support if the hash remains absent.

Keep the original off-ramp status as `failed` in your test fixture even after adding `refundTransactionHash`. Automatic off-ramp refunds do not create a separate `type: "refund"` transaction.

```json
{
  "success": true,
  "data": {
    "transactionId": "sandbox-offramp-refund-test",
    "chargeStatus": "failed",
    "status": "FAILED",
    "type": "offramp",
    "txId": "0xmock-deposit-hash",
    "refundTransactionHash": "0xmock-refund-hash"
  }
}
```

***

# 📝 Important Notes

* All amounts are in **USDC**
* Conversion is always **USDC → KES**
* Chain must be **BASE** for all test transactions
* Use a **unique `externalReference`** for each test
* Response includes a **deposit address** valid until `expiresAt` timestamp
* A failed sandbox fixture does **not** prove or simulate an on-chain refund