Thank you Koen. I really appreciate your comments and Wim's suggestions. In this case the payment system that we are talking about, works following the first model that you described, i.e. it takes control over the process flow and redirects the user's browser to the payment system site where a standard payment interface (web pages) is used to capture specific payment transaction data (credit/debit card number, user id and others). As you commented, eventually the user browser is redirected to the user's online bank system for further verifications and then goes back to the payment system.
In that scenario and following Wim's recommendations and your own recommendations, I will work implementing the corresponding WResource specializations to deal with each step of the payment flow. Regards. Thanks again. ________________________ Mario Diethelm Guallar ------ Original Message ------ From: "Koen Deforche" <k...@emweb.be> To: "Mario Diethelm Guallar" <mariodiethe...@gmail.com>; "witty-interest@lists.sourceforge.net" <witty-interest@lists.sourceforge.net> Cc: "Wim Dumon" <w...@emweb.be> Sent: 11-08-2015 06:12:59 Subject: Re: [Wt-interest] HTTP question >Hey Mario, > >It's still not entirely clear to me what the payment system expects. > >We have experience with two different types of systems: >- systems that require the user's browser to be redirect to a payment >site where the user will have to confirm the transaction (sometimes >being redirect further to their online bank system for 3D >verification). E.g. this is how Paypal typically works. >- systems where you capture all the relevant information inside your >own web application, and you deal with the 3rd party payment system >purely using web services. The user does not leave your application. > >In the first case, there are different variants, but typically it >involves use of static or dynamic WResource's to handle the redirect >from the third party system back to the wt application. This approach >is a bit more complicated with a Wt application because it's a >single-page application. > >In the second case, it's quite simpler. You only need to a use a HTTP >client to interact with the 3rd party web services. As wim said, the >http client is asynchronous, but you can follow the pattern as >explained in the Http::Client documentation with deferRendering() and >resumeRendering() to fix easily integrate it in a Wt application. This >approach works okay as long as you expect the web services to respond >quickly. Otherwise it's better to user server push instead of >deferRendering() to not block your UI while you are waiting for the >web service to respond. > >Regards, >koen > >2015-08-10 19:59 GMT+02:00 Mario Diethelm Guallar ><mariodiethe...@gmail.com>: >> Thank you Wim. I will work following your recommendations. >> >> As far as I understand, to use a WResource I should notify the third >>party >> CGI module (end_transaction) the suggestedFileName that I decide to >>assign >> to the WResource object (equivalent to the ASP script file name) and >> implement the handleRequest function to manage the request/response >>logic. >> What kind of DispossiontType should I use for the WResource (Inline >>or >> Attachment) ? >> >> Regarding the done() signal, if I am not misunderstanding your >>suggestion >> and the Http::Client example, the Wt library will trigger the done() >>signal >> when the running WServer receives the third party answer. Is that >>correct? >> >> Thanks again. Regards. >> >> ________________________ >> Mario Diethelm Guallar >> >> >> >> ------ Original Message ------ >> From: "Wim Dumon" <w...@emweb.be> >> To: "Mario Diethelm Guallar" <mariodiethe...@gmail.com>; >> witty-interest@lists.sourceforge.net >> Sent: 10-08-2015 07:25:43 >> Subject: Re: [Wt-interest] HTTP question >> >> >> Hello Mario, >> >> To process the result, you can as well use a WResource from Wt >>instead of >> the ASP script. >> >> To know when the request was finished and to act on the response of a >> request, connect a method to the 'done()' signal of the client. See >>also the >> code example in Http::Client. >> >> Best regards, >> Wim. >> >> >> On 6 August 2015 at 01:15, Mario Diethelm Guallar >><mariodiethe...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> I am working on the integration of a Wt application (running on an >>>IIS >>> server under Windows) with a third party local payment system. This >>>payment >>> system uses two CGI modules to first start and then return payment >>> transaction results. In a nutshell it works as follows: >>> >>> - you have to call the first CGI module (start_transaction.cgi) from >>>a >>> dynamic Web page using an HTTP POST method with some parameters that >>>you >>> would normally get from the user (transaction amount, user account >>>id and >>> stuff like that) >>> - the local payment system validates and processes the request and >>>then a >>> second CGI module (end_transaction.cgi), informs back transaction >>>results. >>> To do that, this second CGI module expects a dynamic Web page (.ASP, >>>.PHP or >>> other similar) that is invoked by the end_transaction.cgi module and >>>where >>> you can access transaction payment results and complete the >>>transaction with >>> the corresponding answer acknowledge >>> >>> I am planning to use Wt:Http::Cient and Wt::Http::Message classes to >>> implement this application protocol and I would like to validate >>>some of my >>> assumptions: >>> >>> - to activate the first CGI module, I am planning to use the >>> Wt::Http::Client post(url, message) function, where url is the web >>>address >>> of start_transaction.cgi and message is a Wt::Http::Message object >>>with all >>> the requested parameters loaded as "headers" (name, value pairs). >>> - to process the results, I am planning to build a little ASP script >>>(the >>> one that will be used by end_transaction.cgi) that would recover all >>>the >>> information from the answer and would send it back to the Wt >>>application >>> using an HTTP POST method >>> >>> Does it make sense to you? As far as I understand the >>>Wt::Http::Client >>> post is an asynchronous method so I am a little bit confused about >>>how to be >>> sure if the first CGI module actually runs and what Http::Client >>>method do I >>> have to use to get the answer from the ASP script processing the >>>second CGI >>> module response. Is it possible, as an alternative answer processing >>>method, >>> to inform the Wt running application as the dynamic Web page >>>expected by >>> end_transaction.cgi? If this is feasible, what object and method do >>>you have >>> to use to wait for this answer? >>> >>> I would appreciate your comments. >>> >>> >>> Thanks. Regards. >>> >>> >>> ________________________ >>> Mario Diethelm Guallar >>> >>> >>> >>> >>>------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> witty-interest mailing list >>> witty-interest@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/witty-interest >>> >> >> >> >>------------------------------------------------------------------------------ >> >> _______________________________________________ >> witty-interest mailing list >> witty-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/witty-interest >> ------------------------------------------------------------------------------ _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
