Card and ACH
Credit and debit card acceptance through CyberSource, REPAY and Payliance; ACH debits with configurable retry and representment behaviour.
Cash, cheque, debit and credit card, ACH, Check21, prepaid load and instant card funding, with multi-disbursal on a single loan and return handling that posts itself. Every rail writes to the same balance.
Credit and debit card acceptance through CyberSource, REPAY and Payliance; ACH debits with configurable retry and representment behaviour.
Borrower cheque deposit, Check21 processing, redeposit and bank deposit for garnishment — with scanner integration at the counter.
In-store cash with drawer reconciliation, plus MoneyGram for remote cash payment.
Scheduled auto-ACH and card-on-file with configurable retry, grace and notification behaviour.
Return-cheque and NSF handling, refunds, and time-bound rollback and void — each posting to the ledger and the GL automatically.
Servicing →Wells Fargo, Republic Bank, BOK Financial, First Horizon and Royal Bank of Canada among the pre-built banking integrations.
Partners →When the payments gateway is a separate system, every settlement file becomes a matching exercise, and every NSF becomes a manual adjustment in two places.
In QFund the payment, the return, the fee and the accounting entry are one event. Branch close, daily settlement and month-end are reports rather than projects.
Usually not. QFund has pre-built integrations with 21 payment processors, prepaid and banking providers — see the integration ecosystem. Where a processor is not on the list, it is handled through interface and integration services.
Yes — multi-disbursal is supported, so a loan can be part cash at the counter and part instant card funding, with both disbursements recorded against the same loan.
Yes. Payment posting, reversal, auto-pay setup and payment-method changes are all available as RESTful JSON APIs, so a portal or middleware you built can post to the same ledger the branch screens use, under the same permissions and audit trail. Webhooks fire back on the events your systems need — payment posted, payment returned, disbursal completed, status changed — rather than leaving you to poll or wait for a nightly file. API layer →
As posting events. The return reverses the payment, assesses the fee your state configuration permits, updates the delinquency state, re-queues the account for collections if appropriate, and posts the accounting entries — without an agent touching three screens.
Bring a day of real payment and return activity and we will run it through, including the accounting entries it produces.