Funding API

We keep updating our API, exposing more options to our merchants, when integrating with our funding API. In the 5th March release, GET /v2/post-sale/fundings/report payload was enhanced with two more fields:

• ProductType (String)
  • The product type of the original lender's offer for the purchase.
  • Possible values:
    "LineOfCredit",
    "Installments",
    "LeaseToOwn",
    "MerchantSelfFinancing"
• PromoCode (String)
  • The promo code of the original lender's offer for the purchase.
    • Example: "123"

The payload with the additional two fields

{
  "records": [
    {
      "chargeId": "6663c0bd6c45635eaea75aaa",
      "discountAmount": 10,
      "email": "[email protected]",
      "firstName": "John",
      "fundedAt": "2023-11-03T00:00:00Z",
      "lastName": "Smith",
      "lenderName": "Finara",
      "merchantOrderId": "12345",
      "netAmount": 89.99,
      "status": "RECONCILED",
      "transactionAmount": 99.99,
      "transactionDate": "2023-11-03T00:00:00Z",
      "transactionId": "6663c0bd6c45635eaea75aaa",
      "transactionType": "Settle",
      "productType":"LineOfCredit",
      "promoCode":"123",
      "updatedAt": "2023-11-03T00:00:00Z"
    }
  ]
}

Funding API

📘

New API Addition

GET /v2/post-sale/fundings/report is live now and will replace in future
GET /v1 /post-sale/fundings/records and GET /v2/post-sale/fundings/records .

Currently, the ChargeAfter Reconciliation service, also called Funding API, enables merchants to reconcile transactions against the lender's records.
To improve our service, we are upgrading the reconciliation in several ways, mainly around providing order reconciliation instead of single transaction reconciliation.
It will enable our service to be more accurate, exposing a clear status for the whole order (including possible partial settlement or refunds) and also to provide a better performance.

This upgrade comes also with a filtering of the errors (or missing) out of the default responses and therefore merchants interested in retrieving those missing should make sure to use the proper properties as defined below

Important Notes:

• The API responses were not changed between /records and /report, except for the reconciliation status (see below). Therefore almost no development change should apply here besides changing the API endpoint to handle the response, as well as adapting the status if a specific logic was built around those.
• We improved the reconciliation status value UNRECONCILED from a single value to a more precise 2- value status:
  TYPE_MISMATCH will be used whenever the transaction types don't match.
  AMOUNT_MISMATCH will be used when the transaction amounts don't match.
• By default, the results of this API call will not include a transaction in status “MISSING” (lender transaction for which we did not find any match in our system). If you would like to also receive those transactions, please make sure to set the showMissing input param (boolean) as TRUE.

Charges API

• Payload and Parameters were updated with info about Required, MaxLength, and possible expected values (enums).
• Additional Explanations and examples of the HTTP responses were added.