Sankalp Shakti Demo
hcvdshcvdhscvghds
hcvdshcvdhscvghds
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Step 7: Sage Pay servers request card authorisation<br />
The Sage Pay servers format a bank specific authorisation message (including any 3D-Secure<br />
authentication values where appropriate) and pass it to your merchant acquirer over the private<br />
banking network.<br />
The request is normally answered within a second or so with either an authorisation code, or a<br />
declined message. This is obtained directly from the issuing bank by the acquiring bank in real time.<br />
Whilst this communication is on-going, the customer is shown a page containing the text, “Please wait<br />
while your transaction is authorised with the bank”.<br />
Sage Pay handles all authorisation failures by replying to your site with a NOTAUTHED message and<br />
a blank authorisation code after three failed attempts (the first two failures return the customer to the<br />
card selection screen to try another card).<br />
If the acquirer does return an authorisation code, Sage Pay prepares an OK response to send back to<br />
you in Step 8.<br />
If AVS/CV2 fraud checks are being performed, the results are compared to any rulebases you have<br />
set up (refer to our Fraud Prevention Guide available on sagepay.com). If the bank has authorised<br />
the transaction but the card has failed the fraud screening rules you have set, Sage Pay will<br />
immediately reverses the authorisation with the bank, requesting the shadow on the card for this<br />
transaction to be cleared, and prepares a REJECTED response.<br />
Some card issuing banks may decline the reversal which can leave an authorisation shadow on the<br />
card for up to 10 working days. The transaction will never be settled by Sage Pay and will appear<br />
Sage Pay Form Integration and Protocol and Guidelines 3.00 Page 16 of 61