Share
Explore

icon picker
General-Purpose Offline Bank Transfer Funding via Webhook

1. Objective

Allow users to fund any Sycamore product (wallet, investments, savings, etc.) via bank transfer. The system uses a webhook to auto-detect transfers, match them to user funding intents, and credit the appropriate product. Unmatched transfers are refunded to the user’s Sycamore wallet. The sender's name is logged and used for enrichment and potential fallback logic but not as a primary matching criterion.

2. Problem Statement

Offline transfers are popular among users, but manual handling causes errors and delays. Automating the process via webhook improves efficiency, user trust, and scalability. Including sender name in webhook logs enhances traceability, fallback matching, and fraud checks.

3. Goals

Allow users to fund any Sycamore product via bank transfer
Auto-match incoming transfers using webhook data
Auto-credit investment on success.
Auto-refund unmatched transfers to Sycamore wallet
Enrich logs with sender name for traceability and fallback logic
Provide view-only admin visibility into all offline transfer events

4. User Stories

As a user, I want to fund any product via transfer and get confirmation when successful
As a system, I want to detect incoming transfers and match them to pending funding intents
As a system, I want to refund unmatched or invalid transfers to the user's wallet and log the sender’s name for review
As an admin, I want to view offline funding attempts, their status, and the sender’s name for context

5. User Flow

1. Initiate Funding (Mobile App)

User selects product to fund (Wallet, Investment, Savings, etc.)
Enters funding amount
Chooses Bank Transfer
Sycamore displays:
Static or dynamic bank account (e.g., Providus)
Account name
Unique Reference Code (e.g., FUND-14220-K2J8M)
Instructions to include the reference code in narration
System creates a funding intent
Status: Waiting Payment

2. Make Bank Transfer

User transfers the exact amount from their bank app
Includes the Reference Code in the narration

3. Webhook Detection (Backend)

Providus webhook sends incoming credit event
System captures:
Amount
Bank narration
Timestamp
Sender Name (e.g., "ADEKUOROYE EMMANUEL")

4. Auto-Match Logic

System attempts to match transfer to a funding intent using:
Reference Code (primary)
Amount
Time Proximity (±30 minutes)
Sender Name is not used in matching, but is stored and displayed for review.

5. Match Success

Intent is matched
System credits the selected product (wallet, investment, etc.)
Status: Completed or Active
Notification sent to user

6. Match Failure

No matching funding intent found
Transfer is marked Rejected
Amount refunded to Sycamore wallet
Sender name is retained in logs
Status: Refunded
Notification sent to user with rejection reason

6. Sprout Admin (View-Only Access)

Path: Wallet → Offline Transfers
Admins can only view offline transfers.

Filter Options

Status: Completed, Refunded, Rejected
Date Range
User ID
Reference Code
Sender Name

Each record displays:

Amount
Timestamp
Bank narration
Extracted Reference Code
Matched Product and ID (if matched)
Rejection reason (if any)
Refund status (if applicable)

Sender Name (from webhook)
🔒 Admins cannot approve, reject, hold, or upload receipts.


7. Statuses
Status
Description
Waiting Payment
Funding intent created, awaiting transfer
Completed
Transfer matched and product credited
Active
Product activated (if investment or savings)
Rejected
Transfer could not be matched
Refunded
Rejected transfer refunded to Sycamore wallet
Failed
Error occurred during processing or refunding
There are no rows in this table

8. Reference Code Format

FUND-<UserID>-<ShortCode> e.g., FUND-14220-K2J8M Displayed to the user and must appear in transfer narration


9. Notifications
Event
Type
Message
Transfer matched
Push + In-app
Your [product] has been successfully funded
Transfer rejected
Push + In-app
Transfer could not be matched: [Reason]
Wallet refunded
Push + In-app
₦X has been refunded to your Sycamore wallet
There are no rows in this table


10. Error Handling & Fallbacks
Issue
Handling
Missing or incorrect reference
Auto-reject & refund
Mismatched amount
Auto-reject & refund
Webhook delay or failure
Implement retry logic or fallback polling
Duplicate transfers
System detects and refunds duplicate to wallet
No matching intent
Auto-reject or log for future intent correlation
Suspected fraud or abuse
Log sender name for escalation or blacklisting
There are no rows in this table

11. Audit & Logging

System logs every transaction with:
Webhook event
User ID (if matched)
Reference Code
Sender Name
Matched product (if any)
Status change history
Refund status and reason
All records are queryable by admin for review only.

Offline Bank Transfer Payment with Receipt Upload for Confirmation.


Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.