eFaaS acceptance testing

What to do: A customer with K0 in their wallet requests K10,000 of goods through your platform. Record their permission, order and supplier. Get your business approval if the product requires it, then MightyFin’s credit decision. The customer accepts the offer. MightyFin separately approves payment. Check that the supplier is paid, then record repayments.

What should happen: The request, purchase, payment and repayments match for everyone. Your approval does not replace MightyFin’s approval. Approved credit is not wallet cash. This full journey is not yet signed off: spending restrictions, supporting documents and supplier payment still need testing.

What to do: Use your sandbox Client ID and secret. Request only the permissions your application needs. Check the available API list, try a paged list and retry a request safely.

What should happen: The API allows only the requested permissions. Missing credentials, page sizes above the limit and changed retry requests return clear errors.

What to do: Submit your business details and documents. If MightyFin asks for corrections, update and resubmit them. After staff approval, register a customer and upload their documents with the required permission.

What should happen: Staff see the correct documents. Other businesses and applications cannot access them. Sandbox identity checks use test data; they do not verify real people.

What to do: Submit an application from your platform. Answer any requests for more information. MightyFin staff review it. Read the offer and record the customer’s acceptance.

What should happen: Your platform can show the status and history. Test declined applications, expired or reduced offers, cancellation and repeated acceptance. Accepting an offer does not release money.

What to do: Find the loan account created after the offer is accepted. MightyFin staff choose the funding source and separately approve the test payment. Check its final status.

What should happen: The loan becomes active only after the payment is confirmed. Pending, failed or repeated requests must not release extra money or activate the loan early.

What to do: Create two test wallets, add test money and transfer some between them. Register a webhook URL to receive updates. Verify the message signature and compare the update with the transaction. Retry the same request and test a failed webhook delivery.

What should happen: Balances match the transactions. Retries do not move money twice. Updates reach only the correct application. Payments fail safely when funds are insufficient. Test payments do not prove live bank connections work.

What to do: Complete a test loan through approval and funding. Read its payment schedule, make a repayment and check how it reduces principal, interest and fees. Test late payments, overpayments and supported payment reversals.

What should happen: The schedule, account records and reports agree. Pending applications are not counted as loans. Retrying a repayment does not collect twice.

What to do: Use an approved test loan and the correct customer. Follow the available steps to record the order, documents and delivery. Raise a dispute where supported. Check availability first.

What should happen: The loan, supplier and documents belong to the correct transaction. Recording delivery does not prove the supplier was paid or create more credit. The full purchase-and-payment journey still needs testing.

What to do: Repeat tests with a second business using the same permissions. Arrange tests with MightyFin for many requests at once, unavailable services and restoring backups. Do not run heavy tests against the live service.

What should happen: Businesses cannot see one another’s records. Failures do not lose updates or move money twice. Live payment connections, recovery procedures and production access need separate approval.

What to do: Let a signed-in customer request finance, upload documents, accept or decline an offer, check payments due and view history. Test repayments and statements where available.

What should happen: Your server calls the APIs; never send your Client secret to the customer’s browser. A customer cannot act for someone else. Statements and other planned features must not be shown as available until released.

What to do: Have an authorised employee request K15,000 for a customer’s stock purchase. Record the employee, customer, product, customer permission and required documents. Keep your business review separate from MightyFin’s credit decision.

What should happen: No debt is created without the required permission and acceptance. You can see who took each action and retain the original request and documents.

What to do: Check who can use each product and which limits apply. Test customer requests and requests made by your staff. Follow your business approval step where required, then MightyFin’s review.

What should happen: Your business can offer only approved products. MightyFin staff still make credit decisions. Automatic approvals, sharing a limit between customers and other planned models are not available unless explicitly released.

What to do: Request K10,000 and have MightyFin offer K7,000. Test accepting, declining and letting the offer expire. Try cancellation only at allowed stages. If terms can be changed, record the customer’s agreement again.

What should happen: The original request stays visible. A K7,000 offer cannot pay out K10,000. A declined application creates no credit. Changing terms must not silently change an existing loan.

What to do: For a product that supports it, start with K10,000 available credit. Use K7,000, then K3,000. Repay K4,000 towards the borrowed amount. Check interest and fees separately. Test whether the product allows borrowing again after repayment.

What should happen: Wallet money, available credit and debt are different. K10,000 falls to K6,000 only if all K4,000 reduces the borrowed amount; interest or fees may take part of a payment. An ordinary loan repayment does not create new credit. Borrowing again under the same limit needs a product that supports it; that feature still needs testing and release.

What to do: Create several customers with different loan amounts and one with no loan. Repeat under a second business. Check your business totals and MightyFin staff’s permitted views of customers, loans and transactions.

What should happen: Customers’ balances and histories never mix. You see only your business’s records, even if a customer also uses another business. Totals match the individual accounts you are allowed to view.

What to do: For MightyFin-funded loans, check the funding source, who is owed the money, where repayments go and who receives interest and fees. Test other funding arrangements separately when available.

What should happen: MightyFin staff approve funding. Funding from your business, another partner or a mix of sources is not available just because it has a label; it needs an agreed product, working payment records and completed tests.