Finbase BBPS Refund, Reversal and Failed-Transaction Policy

This policy explains when Finbase will reverse or refund amounts arising from wallet loading and BBPS bill payments, how the amount will be returned, the expected timelines, and how an agent or customer may raise a dispute. It is designed for Finbase's closed-loop wallet workflow, in which an authorized Finbase sales agent loads funds into an Finbase sub-wallet and uses that wallet to initiate bill payments. The policy is intended to ensure that a failed transaction is not treated as a completed payment merely because the agent's wallet or funding account was debited. Finbase will use the transaction status received from BillDesk/BBPS, payment-network status, biller confirmation, and Finbase's reconciliation records to determine the appropriate resolution.

Scope

This policy applies to:

Wallet loads initiated by an Finbase channel partners/sales agent through the Finbase application and redirected to the BillDesk payment gateway using UPI, NEFT, debit card, or another payment method enabled by Finbase.
BBPS bill payments initiated from an Finbase agent sub-wallet through BillDesk's BBPS service.
Reversals, refunds, duplicate-payment handling, delayed confirmations, reconciliation breaks, complaints, and related compensation where required by applicable RBI or payment-system rules.

This policy does not create a right to cancel or reverse a bill payment that has been successfully accepted and settled by the biller, except where the biller, BBPS rules, BillDesk, or applicable law provides a correction or refund mechanism.

Definitions

Term	Meaning
Agent	An authorized Finbase sales agent using the Finbase application.
Finbase wallet / sub-wallet	The closed-loop balance maintained by Finbase for an eligible agent and used only for permitted Finbase services.
BBPS	Bharat Bill Payment System.
BBPS reference number	The reference generated for a BBPS transaction and used for tracking, reconciliation and dispute management.
BillDesk	The payment gateway and/or BBPS service provider engaged by Finbase under the applicable agreement.
Biller	The utility, service provider or other biller to whom the bill amount is payable.
Failed transaction	A transaction that was not fully completed for a reason not attributable to the customer or agent, including a communication failure, timeout, unavailable service, or failure to obtain a final confirmation.
Reversal	Restoration of a debited amount to the same funding source or Finbase wallet from which it was debited.
Refund	A return of money after a payment has been determined to be refundable under this policy, the biller's rules, the BillDesk agreement, or applicable law.
Successful payment	A transaction that was not fully completed for a reason not attributable to the customer or agent, including a communication failure, timeout, unavailable service, or failure to obtain a final confirmation.

Core principles

Finbase will apply the following principles:

No double recovery. Finbase will not refund the same transaction twice. If a biller or payment provider has already refunded the amount, Finbase may close or adjust the corresponding Finbase claim after verification.
Same-source restoration. A wallet debit will ordinarily be reversed to the same Finbase sub wallet. A wallet-load failure will ordinarily be reversed to the original payment source, subject to the payment method and BillDesk's settlement process.
Final status controls. A transaction marked pending will not be treated as successful or failed until the status is resolved through BillDesk/BBPS or reconciliation.
No agent-created status changes. Agents must not manually mark a payment successful, retry a pending payment without checking status, or represent that a bill has been paid without a receipt or final confirmation.
Applicable timelines are minimum protections. The applicable RBI, NBBL/BBPS, payment-network and contractual BillDesk timelines will apply. Where two timelines differ, Finbase will apply the shorter or more customer-protective timeline.
Automatic action. Where the applicable framework requires an automatic reversal or compensation, Finbase will process it without requiring a separate claim from the affected person.
Auditability. Finbase will preserve the wallet ledger entry, payment identifier, BBPS reference number, timestamps, status history, callback data, reconciliation result, and refund/reversal evidence.

Wallet-load refunds and reversals

Successful wallet load After BillDesk provides a verified success callback and Finbase completes its validation, Finbase will credit the agent's sub-wallet and generate a load receipt. The master wallet ledger will record a CREDIT entry with the transaction ID, amount and timestamp. A successful wallet load is not refundable merely because the agent later decides not to use the balance. Any permitted withdrawal, closure or balance-settlement arrangement must be governed by a separate agreement and applicable law. Finbase may reject a request where the funds have already been used, are subject to a dispute, or are connected with suspected fraud or prohibited activity.
Debited but wallet not credited If the agent's bank or card account is debited but the Finbase wallet is not credited, Finbase will first place the transaction in pending/reconciliation status and will not ask the agent to make an unnecessary second payment. Finbase will use BillDesk's payment status and will send information about the refund status to the respective partner or agent confirmation. If the payment is unsuccessful or cannot be confirmed within the applicable payment-network or RBI timeframe, Finbase will support an automatic reversal to the original payment source. BillDesk will return the funds to the agent's source account.
Duplicate wallet load If the same funding transaction is credited more than once due to a technical or reconciliation error, Finbase will request billdesk to suspend the duplicate amount and reverse the duplicate credit. The original valid wallet load will remain unaffected.

BBPS bill-payment refunds and reversals

Pre-payment validation Before initiating payment, the agent must select the correct biller, enter accurate consumer or account details, review the fetched bill, and confirm the amount with the customer. If the Finbase wallet balance is insufficient, billdesk may reject the request and will not debit the wallet. Finbase is not responsible for a successful bill payment made using incorrect consumer details, an incorrect biller, or an amount expressly confirmed by the agent/customer, except to the extent that the biller, BillDesk/BBPS rules, or applicable law provides a correction or refund route. The agent must not submit a payment without showing the bill details and obtaining the customer's confirmation.
Successful bill payment When BillDesk/BBPS returns a final success and the biller accepts the payment, billdesk will generate a receipt and update the transaction status. The master wallet ledger will record the debit, transaction reference, amount and status, and later associate the BBPS reference number and timestamp. Once the biller has successfully accepted or settled the payment, Finbase will not independently reverse the wallet debit. A refund request must be handled under the biller's refund/correction rules or the applicable BBPS dispute process. Finbase will assist the customer or agent by providing the transaction and BBPS reference details.
Wallet debited but bill payment failed If the wallet is debited and BillDesk/BBPS reports a failed transaction, billdesk will reverse the full debited amount to the same agent sub-wallet after receiving the failure/reversal result or funds through the applicable settlement process. The ledger will record a REVERSAL/CREDIT linked to the original debit.
Wallet debited and status is pending or no confirmation is received A timeout, absent callback, communication failure or conflicting status will be recorded as PENDING. The agent must not immediately initiate a second payment. Finbase will query BillDesk/BBPS, request reconciliation, and billdesk will either:
1. Update the transaction to SUCCESS and retain the wallet debit if the biller confirms payment;
2. Update the transaction to FAILED/REVERSED and credit the wallet if payment was not completed; or
3. Keep the transaction pending until the applicable final-status and reversal process is completed.

If a second payment is made before the first payment is resolved, any duplicate-payment outcome will be investigated under Section 6.5 and will not automatically qualify for a refund.

Duplicate bill payment

A duplicate bill payment exists where two or more successful payments are made for the same bill or consumer account within a relevant billing period. billdesk will submit the duplicate claim through the applicable BillDesk/BBPS/biller process and provide the customer with the complaint reference number.

Refund eligibility and timing will depend on the biller's rules, whether the biller has received and applied both payments, and the outcome of the BBPS dispute process. Finbase will not promise a refund.

Biller-side non-application or delayed posting

If the customer's account is debited and the biller does not show the payment, Finbase will raise a trace using the BBPS reference number and transaction identifiers. Where the payment was successfully settled to the biller, the matter will generally be treated as a biller posting or reconciliation issue rather than an Finbase wallet refund. Finbase will provide the transaction evidence and pursue correction through the BillDesk/BBPS complaint channel.

How to raise a complaint or refund request

A complaint should be raised through the Finbase application, agent support channel, customer support email, or other channel published by Finbase. The complainant should provide the following information:

Transaction ID and BBPS reference number, if available;
Date and time of payment;
Amount and payment method;
Biller name and consumer/account number, with sensitive information masked where possible;
Agent ID or registered mobile number; and
Bank statement, payment confirmation, receipt or screenshot when requested.

Finbase will acknowledge the complaint, classify it as wallet load, failed payment, pending payment, duplicate payment, wrong-detail payment, unauthorized transaction, or another category, and provide status updates. Finbase will use the BBPS reference number for escalation and tracking where the matter is routed through the centralized BBPS dispute framework.

The complainant must not share a UPI PIN, card PIN, password, one-time password, full card security code, or wallet login credentials with Finbase, BillDesk, a biller, or an agent.

Escalation and grievance redressal

Finbase will maintain a published grievance-redressal structure with the name/designation of the nodal officer, support channels, and escalation timelines. The final production version of this policy must insert the following details:

Level	Owner	Channel	Response / resolution SLA
Level 1	Finbase Customer Support	support@finbasetech.com	Acknowledge within 2; resolve or update within 5
Level 2	BillDesk / BBPS escalation	[contractual channel]	As per BillDesk/BBPS SLA

Unauthorized or suspicious transactions

An agent or customer must report an unauthorized, altered, or suspicious transaction immediately through Finbase's published support channel. On Finbase request, bildesk may freeze the affected wallet balance, suspend the relevant agent account, request evidence, the payment network, the bank, BBPS, and law-enforcement authorities. Resolution will follow the applicable unauthorized transaction, fraud, chargeback and dispute rules.

A refund is not guaranteed where the loss resulted from credential sharing, social engineering, negligence, or an unauthorized act, except to the extent required by applicable law or the relevant payment-system rules. Prompt reporting remains essential.

Exclusions and limitations

Finbase is not responsible for a delay caused solely by a customer's or agent's incorrect information, failure to provide requested proof, bank or card-issuer processing outside Finbase's control, biller policy, force majeure, or a lawful regulatory or law-enforcement hold. These limitations do not remove any mandatory reversal, compensation, grievance, data-protection, or consumer-protection obligation.

Nothing in this policy limits a person's rights under applicable law or prevents a competent authority from directing a different resolution.