3DS FAQ: Difference between revisions

From Barion Documentation
Jump to navigation Jump to search
No edit summary
m (replaced reference to v2 GetPaymentState with v4 PaymentState)
 
(41 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__TOC__
{{PageTitle|title=3DSecure FAQ}}
{{TableOfContents}}


== Ilyen formátumú TraceID-ket kapunk tőletek: <code>0MHSGZRZ1G0118      0</code>==
Here, you can find the frequently asked questions related to the Barion 3D Secure solution. The content of this page is updated if any issues surface or clarifications are needed.
Ezeket a kártyakibocsátó generálja. 100 karakteren belül bármi lehet, és a 0-k és szóközök fontosak, nem lehagyhatóak!


== TokenPayment subsequent fizetéseknél már nem kell megadni a 3DS azonosításhoz szükséges adatokat? ==
If you have any questions related to 3D Secure not covered in this FAQ, reach out to us at [mailto:[email protected] [email protected]], where we can provide more in-depth, case-specific answers, depending on the issue you encountered.
De! A RecurringPayment-ekhez leírás itt: [[Token_payment_3D_Secure|Token Payment 3DS]] Subsequent paymenteknél annyi változik, hogy az ügyfélhitelesítés nem történik meg.


== A fizetések elindítása során megadott adatok közül mi az, ami kötelező megadni, hogy 3D Secure biztos legyen? ==
== Upon starting the payments which properties are required? ==
Ezek a mezők új 3ds fizetések esetén ERŐSEN JAVASOLTAK. (Értsd – az endpoint nem dob hibát, ha nélkülük érkezik a request.) A tartalmukban a fieldek opcionálisak (elvileg beküldhető üres array/map). Azonban a több = jobb elv érvényesül. A kártyakibocsátó ezeket a mezőket felhasználja a kockázati elemzés során és ennek megfelelően dönthet a tranzakció elutasításáról / challenge kéréséről / challenge nélküli jóváhagyásról.
We highly recommend using the properties marked with {{3dsfield}} badge in the [[Payment-Start-v2|PaymentStart]] request. There is no ''Read: error'' thrown when sent without these properties. The content of these fields is optional. Payments undergo Transaction Risk Analysis on the card issuer side based on these data as well, deciding if the payment should be challenged or not.


== Az első Payment/Start kérésnél, a “TraceId” értékét nekünk kell legenerálni és megadni, vagy pedig ezt a Barion rendszere generálja le ?==  
== We've received TraceId in the following format: <code>0MHSGZRZ1G0118      0</code>==
A TraceId-t a kártyakibocsátó generálja, tehát az token inicializálásnál nem kell küldeni. Nektek tárolni kell a kapott TraceId-t és subsequent paymenteknél küldeni. Erről [[Token_payment_3D_Secure#1.3_Processing_the_callback_and_requesting_information_about_the_result_of_the_payment]||itt] van info.
The TraceId is generated by the card issuer and can be anything up to 100 characters. Whitespaces and 0s should also be left intact. You can read more about the TraceId [[Token_payment_3D_Secure#TraceId|here]].
Ez alól kívételt képez egy ideig a már inicializált ismétlődő fizetések ismételt fizetései. Erről [[Token_payment_3D_Secure#Changing_the_token_payment_scenario_with_an_existing_token|itt]] van info:
 
== Can we skip the additional data in subsequent payments that were required for 3DS authentication in the first Token Payment? ==
Additional data can't be ignored! The difference between the initial and subsequent token payment is that 3DS authentication is only required for the first, initial payment. More info can be found [[Token_payment_3D_Secure|here]]
 
== Do we have to generate the TraceId in the first [[Payment-Start-v2|Payment/Start]], or is it generated by Barion? ==
TraceId is generated by the Card Issuer, so it is not required in the initial [[Payment-Start-v2|Payment/Start]] request. You have to store the TraceId, received in the [[Payment-PaymentState-v4|PaymentState]] response, and send it in all subsequent payments. You can read more [[Token_payment_3D_Secure#1.3_Processing_the_callback_and_requesting_information_about_the_result_of_the_payment|here]]. The exceptions are the subsequent payments of an already initialized token payments without 3DS. More info can be found [[Token_payment_3D_Secure#Changing_the_token_payment_scenario_with_an_existing_token|here]].
 
== When the amount of the first payment is different than the rest, I have to use [[RecurrenceType|MechantInitiatedPayment]] and not [[RecurrenceType|RecurringPayment]]. Right? ==
Yes, RecurringPayment can only be used when the amounts of all the subsequent payments are the same or less. If only 1 is different (for example, you give discount/free for the first month), only MechantInitiatedPayment can be used. You can find more info [[Token_payment_3D_Secure#Token_payment_scenarios|here]].
 
== What is a soft decline? ==
When an exemption is requested (MIT, REC, TRA), the card issuer reserves the right to decline the charge with the exemption (could be identified by <code>ScaSoftDeclined</code> as the <code>FundingInformation</code> -> <code>ProcessResult</code> in the <code>GetPaymentState</code> response). In this case, a full 3ds authentication is required (hence the name "soft decline"), and the charge could be attempted again.

Latest revision as of 10:34, 25 March 2024

3DSecure FAQ

Here, you can find the frequently asked questions related to the Barion 3D Secure solution. The content of this page is updated if any issues surface or clarifications are needed.

If you have any questions related to 3D Secure not covered in this FAQ, reach out to us at [email protected], where we can provide more in-depth, case-specific answers, depending on the issue you encountered.

Upon starting the payments which properties are required?

We highly recommend using the properties marked with

3DS

badge in the PaymentStart request. There is no Read: error thrown when sent without these properties. The content of these fields is optional. Payments undergo Transaction Risk Analysis on the card issuer side based on these data as well, deciding if the payment should be challenged or not.

We've received TraceId in the following format: 0MHSGZRZ1G0118 0

The TraceId is generated by the card issuer and can be anything up to 100 characters. Whitespaces and 0s should also be left intact. You can read more about the TraceId here.

Can we skip the additional data in subsequent payments that were required for 3DS authentication in the first Token Payment?

Additional data can't be ignored! The difference between the initial and subsequent token payment is that 3DS authentication is only required for the first, initial payment. More info can be found here

Do we have to generate the TraceId in the first Payment/Start, or is it generated by Barion?

TraceId is generated by the Card Issuer, so it is not required in the initial Payment/Start request. You have to store the TraceId, received in the PaymentState response, and send it in all subsequent payments. You can read more here. The exceptions are the subsequent payments of an already initialized token payments without 3DS. More info can be found here.

When the amount of the first payment is different than the rest, I have to use MechantInitiatedPayment and not RecurringPayment. Right?

Yes, RecurringPayment can only be used when the amounts of all the subsequent payments are the same or less. If only 1 is different (for example, you give discount/free for the first month), only MechantInitiatedPayment can be used. You can find more info here.

What is a soft decline?

When an exemption is requested (MIT, REC, TRA), the card issuer reserves the right to decline the charge with the exemption (could be identified by ScaSoftDeclined as the FundingInformation -> ProcessResult in the GetPaymentState response). In this case, a full 3ds authentication is required (hence the name "soft decline"), and the charge could be attempted again.