# Update past transaction

Update past transaction in preparation for line of credit migration.

Note: After migration, you should call the "Update transaction" endpoint.

Endpoint: PUT /people/{personId}/loans/{loanId}/migration/past-transaction/{transactionId}
Version: 2025-03-26
Security: oauth2, bearerAuth, apiKeyHeader

## Path parameters:

  - `personId` (string, required)
    A Borrower's unique identifier, tied to a person or a business. Can be Peach or a lender's external identifier.

  - `loanId` (string, required)
    The unique identifier of the Loan we wish to retrieve. Can be
Peach or lender's external identifier.

  - `transactionId` (string, required)
    Transaction ID. Can be Peach or lender's external identifier.

## Request fields (application/json):

  - `amount` (number)
    The amount of the payment.

  - `externalId` (string)
    A lender's identifier for a resource.
After the resource is successfully created, a lender can use the Peach assigned ID OR
the `externalId` identifiers to fetch the resource.
### Fetching with `externalId`:
To fetch a resource using an `externalId`, you MUST use the prefix `ext-` in the URL.
For example, a loan with an external identifier of `ABCDE` would be referenced like `/api/people/BO-FAKE-IDNT/loans/ext-ABCDE`.
### Creating with `externalId`:
To create a resource with an external identifer, you MUST NOT use the prefix `ext-`.
For example, if the external identifier should be `ABCDE`, then pass
`{ externalId: "ABCDE", ... }` in the request body.

  - `failureReason` (string)
    The transaction failure reason.
    Enum: "insufficientFunds", "chargeback", "accountClosed", "invalidAccount", "unknownReason", "invalidCvv", "invalidExpirationDate", "avsFailed", "networkError", "cardDeclined", "accountFrozen", "deceased", "invalidRouting", "paymentStopped", "microdepositsFailed", "microdepositsAttemptFailed", "incorrectNumber", "fraudulent", "unauthorizedDebit"

  - `status` (string)
    The transaction status. May only be passed when `isExternal=true`.
External transactions can be created in: `scheduled`, `initiated`, `pending`, `succeeded`, or `failed`.
External transactions are applied to the loan balance immediately when created with status `initiated`, `pending`, or `succeeded`. Otherwise,
they will be applied the first time they are updated to one of these statuses.
`initiated` - payment was initiated and sent to a payment processor. The payment is applied to a loan. This status is used normally for ACH.
`pending` - payment was acknowledged by the payment processor and is being processed. For ACH the payment can be in pending status for a few days.
`succeeded` - payment was completed successfully.
`failed` - payment failed and was removed from the loan effective as of `initiated`, `pending` or `succeeded` status effective date. The system replays the loan as if the payment never happened.
It will also re-accrue interest since then.
`inDispute` - payment is in dispute (typically because of chargeback). The payment is removed from the loan effective as of `initiated`, `pending` or `succeeded` status effective date. The system replays the loan as if the payment never happened.
It will also re-accrue interest since then. Disputed payment can be for partial amount.
`canceled` - payment or credit was canceled. Payment can be canceled only if the current status is `scheduled`.
`chargeback` - payment was disputed and ruled against the lender. The payment was returned to the original payment instrument. Chargeback payment can be for partial amount.
    Enum: "initiated", "pending", "succeeded", "failed", "canceled", "inDispute", "chargeback"

## Response 200 fields (application/json):

  - `message` (string)
    Description of the server action or error.

  - `status` (integer)
    HTTP status code.

  - `data` (object)

  - `data.migration` (object)
    Transaction migration related details. This object:
- Can be used only for transactions with an effective date before the "migration cutoff date".
- Can be used for lines that are migrated from another system to Peach. Don't use it for installment loan migration.
- Allows you to pass details on how a transaction was applied/allocated to draws.

For example:
Line of credit had three draws prior to the "migration cutoff date". Balances of draws were:
- Draw A: $650
- Draw B: $70
- Draw B: $0

A payment of $120 was processed. Using this object you can tell the system that $120 was waterfalled/allocated as following:
- Draw A split: $70
- Draw B split: $50
- Draw A split: $0

If you don't pass the `migration` object, then you won't be able to make the following status changes after the "migration cutoff date":
`pending` → `failed`
`succeeded` → `failed`

  - `data.migration.drawSplitDetails` (array)
    The transaction draw level split details are useful if the lender expects failures of previous successful transactions.
When a transaction is applied on the line of credit level, it flows according to the payment waterfall configuration across
multiple draws. At least one element in the `drawSplitDetails` array is required.

  - `data.migration.drawSplitDetails.drawAllocatedAmount` (number)
    The portion/split of the transaction `actualAmount` that was applied/allocated to the `originalDrawId` draw. The sum of all
`drawAllocatedAmount` must be equal to the transaction's `amount`.
If the transaction fails after the "migration cutoff date", the system will increase the applicable "originalDrawId" draw's
non-due principal balance and replay the line.

  - `data.migration.drawSplitDetails.originalDrawId` (string)
    The draw identifier. Can be Peach or lender's external identifier.
All past transactions prior to the "migration cutoff date" will be posted on the "migration" draw. After the "migration cutoff date",
a lender can have multiple draws (e.g. Purchases, Cash Withdrawals, etc.) Use this attribute to indicate the original draw ID that
the transaction was posted on in another system. In case of transaction failure after the "migration cutoff date", the `originalDrawId`
will be used to increase the draw's "non-due principal" balance.
Transactions can be posted on the line or draw level. If the transaction was originally posted on the draw level, choose one of the
post migration draws (e.g. Purchases).