The payload of the GET /v2/checkout/applications/{applicationId}/statusendpoint that retrieves the status of an application has been upgraded.
The following response parameters have been added:
applicationStatus: The latest application status corresponding to the applicationId.
Possible values:
Prequalified
PendingConsumer
PendingLender
Approved
Authorized
Declined
account: The latest lender account to which the consumer was redirected in ChargeAfter's Checkout flow with the details of the lender and the remaining credit info.
lenderName
lenderId
creditInfo (subject to lender support of OTB/open to buy)
maxAmount
availableCredit
confirmedOffer: The confirmed offer that was used for Checkout.
code
financialProductType
amount
defaultApr
promoSettings
numberOfPeriods
periodicPayment
periodType
apr
Below is a sample 200 response with the new parameters marked:
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.
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.