Add optional params "uppReturnMaskedCC", "useAlias", "uppCustomerDetails"

[fredtro]

Hi there

I have added 3 new parameters according to datatrans technical implementation guide (https://pilot.datatrans.biz/showcase/doc/Technical_Implementation_Guide.pdf) to be able to do 3 different things:

• Request an alias on payment page request by allowing to set uppReturnMaskedCC
• Allowing to set useAlias to be able to authorize a token payment
• Allowing to set uppCustomerDetails to be able to add customer information to datatrans backend

If you like to, you can merge the pull request. Otherwise we will continue on my fork. We will use it on the ongoing/datatrans-bundle. It is an jms payment backend, a simple integration in symfony.

Regards
Frederik

[dpfaffenbauer]

Could you please check why travis fails on running tests?

[fredtro]

Did so. Updated the pull request.

[dpfaffenbauer]

Alright, looks good to me.

Could we also add unit-tests for requests and response with "useAlias" and "uppReturnMaskedCC"? So we handle that case as well?

[fredtro]

Hi there

I don't really know how to test... Because the alias is something which generated by datatrans (a unique identifier for a credit card). The responses are mocked, so you cannot really know if an alias is generated correctly or not.

Then after generating a valid alias, it is just set as creditcard number in XmlAuthorizationRequest. Response will just be an authorization response (and if it is valid it could be settled directly).

Comparable situation with "uppReturnMaskedCC": After user has input his CC Number, datatrans will generate a masked version of it. Then it is send with the response to the given return url.

Or do you have an idea how to test?

[dpfaffenbauer]

So, if you set useAlias to 'yes', whats the difference?

'uppReturnMaskedCC' then returns a masked number in the response action after the capture?

[fredtro]

I see, useAlias is not needed on the authorization request, my fault, i can remove. I think it is just ignored there. Perhaps it should be removed from getData method too, there you set it to useAlias => no.

It could only be used in purchase request. This is from official documentation:

useAlias: Requests the CC alias, this option needs to be activated by Datatrans;
value: “yes”

An yes it is returned after the capture:

uppReturnMaskedCC: “yes” – requests the return of the masked credit card number to
the merchant in field “maskedCC”. See chapter 2.9.1.

[dpfaffenbauer]

seems like useAlias depends on the further gateway as well? It's currently not clear to me where to send it directly.

uppReturnMaskedCC: This will send back the masked number, therefore it set it should come to the response, right? Therefore you could add a test to that.

[fredtro]

Regarding to useAlias:

• at first, you set param useAlias=yes on the purchase request (Gateway->purchase).
• then user is redirected to payment page. After filling out CC data correctly, the response sent to the returnUrl (POST from datatrans server) will contain the aliasCC="somealias".
• after that, this alias could be used in an XmlAuthorizationRequest, which you already set from the CreditCard object (in getData on line 57).
• for all further payments with this card, user don't has to be redirected to datatrans payment page (but could be), you can control that from your client application. This means when you are in possession of the alias, you can send an authorization instead of a purchase request
• when you do that, depending on your datatrans backend configuration you have to do a settlement by using XmlGateway->settlementDebit

to be able to use this feature you need a second merchantid, based on a phone/mail contract, which could be handled by the client application as well (https://admin.sandbox.datatrans.com/showcase/doc/XML_Authorisation.pdf)

Additionally, you can have a look at https://github.com/ongoing/ongoing-datatrans-bundle/blob/master/Client/Client.php. This is where i make use of your omnipay datatrans gateways.

[dpfaffenbauer]

Alright, so a unit-test would make sense. We could test if the response actually has a token inside.

[fredtro]

And the uppReturnMaskedCC will cause that datatrans send back maskedCC field in POST request sent to returnUrl as well. So while testing against mocked responses, it wont be possible to check if it is present/set by datatrans.

[fredtro]

Perhaps i have to look again at your tests properly, it seems that i have missed something. There is a maskedCC in the XmlAuthorizationResponse.txt mock file. Do you mean by adding/extending the Mockfile with aliasCC in it and then checking for it?
Because aliasCC and maskedCC wont be in the direct response, they will be in the POST back of datatrans.

[dpfaffenbauer]

Yes exactly, actually just make a request on test-servers, and copy the expected request/response into mock files and test against them

[fredtro]

Right, i will. As soon as i have the time for it ;) 2018-02-19 12:51 GMT+01:00 Dominik <[email protected]>:

…

Yes exactly, actually just make a request on test-servers, and copy the expected request/response into mock files and test against them — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AETPJpzudnhBNDKAs-87c34nButRUyudks5tWWAygaJpZM4SDkrw> .

[PowerKiKi]

Looks like this PR is ready to be merged. Is there anything else that should be done before merging ?

[dpfaffenbauer]

@fredtro whats your opinion? Everything ready?

[fredtro]

@dpfaffenbauer i think so. there was just a test missing, i think🤔 This week i am on a hackathon, probably dont have so much time. But i can find out whats missing, tonight and will inform you.

[dpfaffenbauer]

👍