Skip to main content
You hold the funds; the Platform holds the record. Money the borrower paid is reported as a receipt. Every figure that follows, what settled, what remains and what closed, is derived from it, and nothing reported is ever edited or deleted: a mistake is corrected by a reversal, which is a further fact. The first receipt of the site’s worked loan is reported call by call on Quickstart; this page carries the rules and the cases beyond it. What lateness costs, penalty, late fee and acceleration, has a page of its own.

​
Reporting a payment

A receipt is addressed to a client, never to a loan: the borrower paid you, and which debt the money settles is the allocation’s answer, not the report’s premise. A designated_loan_id narrows it to one loan when the borrower named one.
Report a receipt
A receipt is never refused for its size. Less than due, more than due, more than the whole loan, and money on a loan that owes nothing are all recorded, the funds are already with you, and refusing the report would not send them back. Stating payoff_intent and electing something else states two things about one payment and is refused.

​
Allocation order

Every allocation answers under the jurisdiction’s rule, and renders the rule beside the result so the order is read, not inferred:
The rule, on every answer
Within a period the money runs penalty, then late fee, then fee, then interest, then principal. Matured periods are walked oldest first, the only order the Platform accepts. Among a client’s several loans when the borrower designated none, the most onerous is settled first, then the oldest; a designation wins over that rule, and chosen_by on each loan’s row says which applied. Two invariants hold in every jurisdiction, and no rule may override them: capital is not deemed paid before interest, and a matured obligation is settled before a later one. Of the order above, only interest-before-capital is fixed by law, art. 2094 of the Código Civil Federal; the rest is the market’s ordinary contractual shape taken at the reading least favourable to the lender. The answer names where every centavo went:

​
What the borrower may choose

Stating nothing is the ordinary case: money settles everything matured, and what remains follows the configuration’s early_money_treatment. An election on the receipt overrides that default for this payment alone. Loans defines the four; here is each in action.

​
Reducing the balance

MXN 2,000.00 past everything matured, elected to principal, on the worked loan with period 1 settled:
The prepayment, allocated
The whole 200000 is prepayment, no period is walked, and recalculated_plan is the statutory result: the term still ends 2027-03-02, and the payment fell from 90066 to 67014 (MXN 900.66 to 670.14), the final period absorbing its own 11-centavo residual as the rounding rule always does. The issued plan is frozen and stays readable on the loan; where the loan stands now is the schedule route, which carries what each period still remains owed and the day each settled period settled:
Read the serviced schedule
The serviced schedule

​
Paying instalments early

The same money electing advance settles unmatured periods at their scheduled figures, oldest first, as far as it reaches. Nothing is recalculated and the term does not move. Two instalments of the second worked loan, paid on 2026-04-13 against periods due in May and June:
The advance, allocated
Each period is walked at its full 90066, and the interest the plan scheduled included, though the days it prices have not elapsed. That overcollection is deliberate, it is what pago adelantado is, and it is exactly what the next case gives back. An advance is worth the same whatever happens to the loan afterwards. It buys no reduction: the principal it settles goes on accruing, and the payoff refunds the scheduled interest beyond the day the borrower discharges. A later act that reprices the plan, a receipt electing principal, a goods return, reprices what the loan still owes and does not reach back into the advance. Two borrowers holding the same loan, one who advanced and one who did not, pay the same to end it once what each is owed back is netted off, whatever repriced it and whenever.

​
Discharging the loan

A payoff is stated, never inferred: payoff_intent on the receipt is what separates a payment one centavo short of the figure from a payoff that missed by one. The figure for a date comes from the payment-options read, which records nothing and is the read for a screen. Record the figure you relay. When a borrower is told “pay this to end the loan”, record the payoff quote: the same derivation answers the same number, recorded with what computed it, and the receipt that pays it names it in quote_id. The allocation then answers quoted_figure_agrees. The record binds nothing — the receipt settles against the figure derived on its value date, exactly as one naming no quote — and it is the evidence for the day a later answer moves: the loan’s payoff quotes. Three captured endings: The second worked loan, paid off on 2026-04-20 after the advance above, shows the netting’s other side:
The payoff, allocated

​
Money owed back

owed_back is the borrower’s money the loan has stopped asking for: the advance collected May and June at their whole scheduled figures, and the payoff then priced those periods at their elapsed days. The 44713 (MXN 447.13) difference is real money the borrower paid, and flooring it away would make it disappear, so it is carried out as an Obligation to the client instead. The other route money comes back is excess, what reached no loan at all. A designated payoff overpaid by MXN 49.49 answers it beside an anomaly naming everything:
201, overpaid
Both stand as one balance on the obligations route, each naming the receipts that produced it:
The client's obligations
Settling that balance with the borrower: refunding it, or agreeing it against future debt, is yours: the Platform records what is owed and to whom, and moves no money.

​
Reversal

A reversal is your record that reported money was not real, a chargeback, a returned transfer, an operator’s mistake. It is a further fact, not a deletion: the receipt stays readable, marked reversed, and every figure it produced is derived again without it.
Reverse a receipt
All four fields are required. reason is the one closed set on this page: chargeback, returned_transfer, operator_error, and reference, actor and basis are the account every irreversible act gives of itself. Recording answers 201; an identical retry 200; the same reference stating anything different, 409 reference_reused. A receipt already reversed refuses a second reversal.
201, the receipt as it now reads
What the reversal undoes, it undoes by derivation. The payoff above had closed its loan; with the receipt reversed the loan reads active again, the derived settled event gone from its facts, and everything it owes stands exactly as the remaining record produces it. A closure is withdrawn by reversing the receipt that caused it, no route closes or reopens a loan by hand.
A reversal states the money was not real. Money that was real and must go back to the borrower, an overpayment, an obligation above, is not a reversal’s case: reversing a genuine receipt would erase a payment that happened. Settle obligations on your own rails, and reverse only what your provider took back.