1

We are implementing a .NET MVC application and planning to use a Hosted Payment Page for Secure Payments and from PCI Stand point.

Am worried the about the data which we might expose in the return call and looking for some best practices implementation.

Am planning to do this as per the hosted payment page expectation on flow

In our MVC application we have a sales page where user add the amount, comments and other required fields and submit

after validating setting the required fields along with the Callback URL redirecting the user to Hosted payment page from different Vendor

Once the transaction is completed the Hosted payment page Call back my Call back URL which is one of the End points in MVC

In the call back URL(Anonymous access) basically am decoding the result they shared in Query string and calling their API to decode and showing the end results to user in the same Sales page(Secured)(where 302 , 200 redirecting from callback url(Anonymous) to sales page(Secured) happens)

My sales page is Secured but my call back URL is exposed So my questions is am i exposing the sales page to Hosted payment page or any security concern by doing this.

I checked this in fiddler if you are not a logged in user you will be redirected to the login page. so what are the security risk am carrying with my current implementation of exposing my callback URL and the call back URL internally redirect to a different action.

What are the best praises to handle this. Please share your ideas

|improve this question
  • Which payment processor are you integrating with? Have you reviewed their documentation? Have you checked their dev site? "Hosted Payment Page" is implemented differently by different providers, so the nuances can be hard to call without looking at specific documentation. – gowenfawr May 18 '18 at 19:31
  • @gowenfawr yes i did. They have Client side redirection for return url and also additional feature where their server directly calling our end point which is an option they are recommending. paymentexpress.com is the Provider – Peru May 21 '18 at 17:06
  • is the "call back URL" for the "Fail-proof Result Notification (FPRN)" feature of PxPay 2.0? – gowenfawr May 21 '18 at 18:20
  • @gowenfawr yes it is feature of PxPay 2.0 – Peru May 21 '18 at 18:32
1

Summarizing my understanding based on question and comments:

  • You are using PxPay 2.0 from Payment Express
  • You using the Redirect method (as opposed to Iframe)
  • You expect the customer's browser to return to you via the UrlFail/UrlSuccess you specify
  • You expect Payment Express to also notify you of status via UrlFail/UrlSuccess
  • Your concern is whether sensitive information might be sent to UrlFail or UrlSuccess, and exposed by lack of encryption

While it's not explicitly defined, all the examples in the PxPay 2.0 Integration Guide show that all calls to the UrlFail/UrlSuccess URLs include two parameters, result and userid:

doco snippet

The result is described as needing to be 'decrypted', but as the decryption process is to look up the meaning with another call to Payment Express, it's almost certainly just a session token with no semantic content, and not useful to anyone without your Payment Express account credentials.

The userid is the username portion of your Payment Express account credentials. While it would be preferable to keep this "secret", and therefore HTTPS would be better, bear in mind that it traverses the customer's browser during the redirect process and therefore is vulnerable to being disclosed, and its secrecy is not a security requirement.

Therefore, I would say that encryption is preferred for your UrlFail and UrlSuccess, but not necessary - there is no information there that is otherwise unprotected by the need for proper credentials to access it.

|improve this answer
  • thank you for the details. Do you think i will be exposing any information to the payment express itself by exposing the anonymous end point which is my sales page itself with other information – Peru May 21 '18 at 21:49
  • @Peru no - but bear in mind, their requirements on the callback URL basically say it should be openly available, so it should be a page anyone could go to and not learn things they shouldn't. – gowenfawr May 21 '18 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.