Simulate Scenarios

This page documents the complete scenarios you can reproduce in Sandbox to test your integration before going to production. Each scenario corresponds to a real business case.

Scenario 1: Successful Mobile Money Payment + Webhook

1. Create a PaymentIntent.
2. Confirm with +24177000001 (Airtel — immediate success).
3. Webhook payment_intent.succeeded received on your endpoint.
4. Check the status: succeeded.

Scenario 2: Mobile Money Timeout

1. Create a PaymentIntent.
2. Confirm with +24177000003 (Airtel — timeout).
3. Wait 120 seconds.
4. Status → requires_payment_method.
5. Offer the buyer the option to retry with another payment method.

Scenario 3: Card Payment + 3DS

1. Mount the Hosted Fields form.
2. Enter the card 4000 0000 0000 3220.
3. The 3DS flow opens automatically.
4. Approve with any OTP code.
5. Status: succeeded.

Scenario 4: Subscription with Trial + Dunning

1. Create a subscription with trial_period_days: 7.
2. Webhook subscription.created received.
3. Wait for the trial period to end (simulated in Sandbox).
4. First charge attempt with +24177000002 (failure — insufficient funds).
5. Webhooks subscription.past_due × 3 (D+3, D+7, D+14).

Speed up time in Sandbox

In Sandbox, subscription retry delays and trial period endings can be simulated immediately with POST /v1/sandbox/advance-clock/ — pass {"days": 14} to advance your App’s Subscriptions by 14 days and immediately trigger the resulting renewal/dunning webhooks.

Do these scenarios cover your testing needs?

Scenario 1: Successful Mobile Money Payment

bash

# 1. Create the PaymentIntent
curl -X POST https://api.sangho.ga/v1/payment-intents/ \
  -H "Authorization: Bearer sk_test_xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 5000,
    "currency": "XAF",
    "payment_method_types": ["mobile_money"]
  }'


# 2. Confirm — +24177000001 = immediate Airtel success
curl -X POST https://api.sangho.ga/v1/payment-intents/pi_xxxx/confirm/ \
  -H "Authorization: Bearer sk_test_xxxx" \
  -H "Content-Type: application/json" \
  -d '{ "payment_method": "meth_xxxx" }'

Scenario 5: Partial Refund

Test the complete partial refund flow: create a payment of 10,000 XAF, then refund 3,000 XAF. The merchant’s net balance is updated accordingly and the refund.succeeded webhook is emitted.

1. Create a PaymentIntent of 10,000 XAF.
2. Confirm with +24177000001 (success).
3. List the PaymentIntent's transactions.
4. Create a partial refund of 3,000 XAF.
5. Webhook refund.succeeded received.

Maximum refund

The refunded amount cannot exceed the original transaction amount. For a full refund, omit the amount field — Sangho will automatically refund the full amount.

Is the refund scenario clear?

Scenario 5: Partial Refund

bash

# 1. Create the PaymentIntent
curl -X POST https://api.sangho.ga/v1/payment-intents/ \
  -H "Authorization: Bearer sk_test_xxxx" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 10000, "currency": "XAF", "payment_method_types": ["mobile_money"] }'


# 2. Confirm
curl -X POST https://api.sangho.ga/v1/payment-intents/pi_xxxx/confirm/ \
  -H "Authorization: Bearer sk_test_xxxx"


# 3. List the transactions
curl "https://api.sangho.ga/v1/transactions/?page_size=5" \
  -H "Authorization: Bearer sk_test_xxxx"


# 4. Partial refund
curl -X POST https://api.sangho.ga/v1/refunds/ \
  -H "Authorization: Bearer sk_test_xxxx" \
  -H "Content-Type: application/json" \
  -d '{ "transaction": "trans_xxxx", "amount": 3000, "reason": "customer_request" }'