How past-dated transactions work

On a loan that isn't being migrated onto Peach, you can create a one-time payment, down payment, or service credit that takes effect at a past date and time, in a single API call. Peach records the transaction at that past instant and runs a Loan Replay™ from it, which recalculates the loan from that instant onward.

This page explains how past-dated transactions work on loans that aren't being migrated onto Peach. To make the call, see the create transaction API reference. Loans being migrated onto Peach follow different rules; see LOC portfolio migration.

• Which creates Peach records at a past instant, and what each one must include
• How the replay recalculates the loan, and what the create response does and does not show
• How to tell afterward that a transaction was backdated
• How the behavior differs by loan type and transaction type

A past-dated transaction is a transaction whose effective date and time are earlier than the moment you create it. You send the instant the payment or credit actually happened, and Peach places the transaction there in the loan's history. Peach then replays the loan from that instant, so everything after it is recalculated.

The create call returns before the replay finishes unless you send sync=true to wait for it. This is different from the separate backdate operation, which changes the effective date of an existing transaction.

• Single-call backdate — a create of a one-time payment, down payment, or service credit that sends effectiveDate and effectiveTimeOfDay and no scheduledDate, on a loan that isn't being migrated onto Peach and whose status accepts the transaction (see Behavior by loan type). Peach records the transaction at that instant and replays the loan.
• Requested instant — effectiveDate plus effectiveTimeOfDay, read in the product timezone, the timezone set on the loan's loan type. It must not be later than the time of the call.
• Loan Replay™ — the recalculation that runs from the requested instant onward.
• Two-step backdate — the separate backdate operation, which changes the effective date of an existing succeeded or pending transaction. It requires the transaction:backdate permission and also accepts paid-off loans.
• Operation ID — the identifier you poll to learn whether the replay has finished. Peach returns it in the X-OPERATION-ID header, or in the 408 response when a waiting call times out.

Peach treats a create as a single-call backdate when the loan is not being migrated, the type is oneTime, downPayment, or service, effectiveDate is present, and scheduledDate is absent. It then checks the request. effectiveTimeOfDay is required. One-time payments and down payments must be external: isExternal is true, or the payment instrument is external. Service credits are exempt from that check. A payment's status must be succeeded or pending; an omitted status is rejected, because it resolves to scheduled.

The requested instant must not be later than the time of the call. A date of today with a time already past is accepted and replays; a later time today returns a 400. Each failed check returns a 400, listed in the past-dated transaction errors reference.

For a one-time payment, down payment, or service credit on a loan that isn't being migrated onto Peach, the three date fields combine as follows.

For a single-call backdate, one-time payments and down payments must also be external, with status succeeded or pending. Service credits are exempt from both checks.

• Known limitation: if you also send scheduledDate, Peach does not apply effectiveDate and returns no error. Leave scheduledDate empty.
• Known limitation: a create on a loan with status paidOff is refused, while the two-step backdate operation accepts a paid-off loan.

Peach saves the transaction with its effective date set to the requested date. pendingAt equals the requested instant, while createdAt records the time of the call. For a succeeded payment, succeededAt equals createdAt. appliedAt stays empty until the replay applies the transaction, which sets it to the requested instant. originalEffectiveDate is also set to the requested date, so it does not show that the transaction was backdated.

By default (sync=false), the create returns 201 Created before the replay finishes. The response carries an X-OPERATION-ID header; poll that operation to learn when the replay is done. With sync=true, the call waits for the replay. If the wait times out, it returns 408 with an operation ID to poll. If Peach hits an error outside the replay itself, for example before the replay starts, it returns 400; the transaction is already saved. See the errors reference.

• Known limitation: with sync=true, the 201 body is the transaction as it was before the replay. Read the transaction again to see its state after the replay.
• Known limitation: a 201, or a completed operation, doesn't confirm that the replay succeeded. If the replay itself fails, the operation still reports success, and a sync=true call returns 201. Replay failures are rare and Peach monitors them, so in general you don't need to do anything.
• Known limitation: without an externalId, Peach cannot recognize a retry as a duplicate, so a retry after a 408 or a dropped connection can create a second transaction. When the first request carried an externalId, a retry with the same value returns 409, which means the first request was saved.

Peach replays the loan from the requested instant and recalculates it from that point onward. Loan Replay™ describes what a replay recalculates.

Loan status changes that the transaction causes, such as paying off the loan, take effect through the replay rather than at the moment of the create. Peach evaluates a payoff during the replay, on balances recalculated from the earlier date, so the loan can be paid off as of a past point. A past-dated payment can pay off a loan that the same payment at today's date would not, because less interest accrues when the payment is moved earlier.

The payoff timestamp doesn't always match that past point. When a past-dated payment pays off the loan and no other succeeded transaction on the loan was applied after it, the loan's timestamps.paidOffAt is the time of the create call, not the payment's requested instant. A past-dated service credit in the same position gives a paidOffAt equal to the credit's requested instant. When another succeeded transaction was applied later, paidOffAt can come from that transaction's succeededAt instead.

A succeeded payment appears on the next day's loan tape, counted from the call date. To see the recalculated loan, read the transaction or the loan after the operation completes.

On September 18, 2026, at 10:15 a.m. product time, an integration records a $250.00 check that the borrower wrote on September 12. It creates a succeeded, external one-time payment on loan LN-7K2P-Q9XD with an effectiveDate of September 12 and an effectiveTimeOfDay of 2:30 p.m.

The create returns 201 with transaction TX-4R8M-2JWC, whose createdAt and succeededAt are 10:15 a.m. on September 18. Peach replays the loan from 2:30 p.m. on September 12. After the replay, the transaction's appliedAt is 2:30 p.m. on September 12, earlier than its createdAt, which marks it as backdated. The payment appears on the loan tape with a report date of September 18, which Peach generates on September 19.

Had the integration sent an effectiveDate of September 18 with a time of 4:00 p.m., later than the call, the create would have returned a 400. A time of 9:00 a.m. that day would have replayed the loan from 9:00 a.m.

The two-step backdate first creates the transaction at today's date and then moves it. Between the two steps, the loan reflects the payment at today's date and can briefly show today's outcome, such as a payoff, until the backdate replays. The single call records the transaction at the past instant from the start, so the loan never shows that intermediate state.

• Down payments — accepted only on loans with status active. One-time payments and service credits also accept accelerated, and chargedOff when the loan type allows payments on charged-off loans.
• Lines of credit — you can send drawId. The requested instant must then be after the draw's startedAt as well as the loan's startedAt (when each was activated).
• Installment loans — no migration cutoff applies.
• Lines of credit migrated onto Peach — when the line has a migration period, the requested date cannot be earlier than its migration cutoff date.

• Loan Replay™ — How a replay recalculates a loan after a retroactive change.
• Past-dated transaction errors reference — Every error a past-dated create can return, with its cause and what to do next.
• Manage payments — Backdate an existing payment from the agent view of the Borrower Portal.