IntegraPay Transaction – Q&A (Paul Richardson)

Home » Payment Gateway - Ezidebit/IntegraPay/Stripe » IntegraPay Transaction – Q&A (Paul Richardson)

4th July 2017:

* Am I right to say a normal successful transaction status would go from “Pending” to “Cleared” to “Settled”? Yes

* What does “Late Rejection (Settled)” mean? Also from business point of view, would the business have already received the money or not at all? This means that the bank has advised us after we have settled the funds to the client that the transaction was in fact dishonoured. In this case the funds are settled to the client and we have then recover the funds from the client. We usually do this next settlement rather than a separate debit.

* In the API doc, the TransactionStatusID value 5 is “Settled” and 8 is also “Settled”. What is the difference between 5 and 8? I’ll find out.

* Is the status “Settled” the FINAL status of a successful transaction? Would there be a case where it changes from “Settled” to something else like “Refunded”? On our side we need to work out definitively what transactions are final and not changing. Credit cards can only be refunded so yes in the case of credit cards. As per above we may get a Late Rejection (Settled). I will find out some timings though on this one.

* The TransactionAmount – this the exact amount that gets processed, meaning the payers will see this amount on their statement, is that right? This is the amount that you send through via the API. The transaction fee could get applied before processing however as we discussed last week, we will ensure that the business pays for the fees and wont surcharge using our system

* Where can I find the settled amount (what businesses actually received) on the Transaction record? eg if transaction amount is $100 and transaction fee is $2, would the $2 or $98 be included in the Transaction record? I’ll find out


From: Customer Integration
Sent: Tuesday, 4 July 2017 2:51 PM
To: Paul Richardson <[email protected]>
Cc: Customer Integration <[email protected]>
Subject: RE: Questions on Transaction API

 

Hi Paul,

 

I’m sending this response just to you at present, in case you wish to reword anything prior to it going to our client.  If you would like me to respond to Mark, please just let me know.

 

  • As a result from our TransactionSearch() API function, a TransactionStatusID value of 5 means fully settled; 8 means partially settled.  A partially settled transaction is one for which the main funds have settled, but the transaction fees have not yet been paid, or vice versa.  Partial settlement has apparently been largely phased out: the only time it is likely to occur now is for clients who are performing direct settled (own merchant) real-time transactions.

 

  • The status of a transaction does normally change to settled (S).  This occurs once the transaction has been processed and the main funds disbursed to the client.

 

  • The status of a transaction can change from settled (S) to late rejected (L), late rejected settled (LS) or refunded (RF) at any time (Jason advises for up to a year).  The issue is that a payer can make a claim/chargeback long after the transaction has settled; hence, we cannot guarantee that a settled transaction will stay settled.  If a chargeback occurs, the bank notifies us by letter and email, at which time we change the status to late rejected (L).  We change the status to late rejected settled (LS) after we recover the money the client owes for the transaction.

 

  • To determine the settled amount received by the business, it is necessary to use our GetNewStatusUpdates() API function, rather than our TransactionSearch() API function.  The former API function provides MoneyRequested, MoneyCollected and MoneySettled values, the last of which is the amount received by the business, as well as various other values that provide information on fees and charges.

 

  • Currently there is no limit on our TransactionSearch() API function, either in terms of timeframe or number of records returned. However, concerns have been raised about potential abuse of this unlimited response, and as such development is considering imposing a 12 month limit in the near future.

 

If any of the above is unclear, please just let me know.

 

 

Cheers,

 

Alistair Grant

.NET / SQL Developer