Today focus on the previous channel server-side SDK, encountered an egg-ache problem to solve. According to the idea that we build u8server before, U8server is able to support a variety of games perfectly. Includes login authentication and payment callbacks. Login authentication, nothing to say. The unified interface can be, and the client's protocol corresponds. What about the payment callback? The payment callback logic for each channel is the same for each game, and then the login callback address that is filled in for each game is the same. u8server adopt the Java EE mature Framework to achieve, the parameters of each game channel, is configured in the database, through the background management tool to complete the addition, modification, deletion and other operations. Before our process, I believe you will remember. Before calling the payment interface, the client will first come to U8server to obtain an order number. At this point, U8server will record a piece of data in the Order data table and return the resulting order number to the client. The client places the order number in the extension field of the Channel SDK or in the Fixed order Number field to the SDK server. The SDK server payment is completed and the callback to U8server will return the order number intact. This time, in the payment callback method for each channel, we first get the order number in the parameters returned by the Channel SDK. Then according to the order number to find the corresponding order information in the database, and then get to the current payment of user information, channel information, game information and other related data this way, for most channels, is OK. But in the AZ and itools, we found that these channels in the payment callback, all the data are encrypted processing, the payment callback method, to get this parameter can not directly get to the order number, you need to get the channel corresponding decryption key to decrypt the encrypted parameters, You can then pick up the order number and other information. This is a conflict with the way we were before. We parse the parameters first, then we get the channel data through the order number, and then we get the configuration data of the current channel from the channel data (the decryption key above). But now these two channels are required, we first decrypt, and then get the order number. However, decryption of the required key, we simply do not get. Because we get the channel data through the order number. later thought, can be through the URL address, directly get to the channel number. For example, before the UC channel, our payment callback address is this: http://192.168.1.88:8080/uc/paycallback then, now, when we configure the channel to pay the callback address, plus the channel number ( For example, the current game corresponds to UC channel number is: http://192.168.1.88:8080/uc/paycallback/10 then, when parsing the URL address, we need to do a URL rewrite in some way. Put a similar URL, to rewrite it in the following form: http://192.168.1.88:8080/uc/paycallback?u8channelid=10 this way, We can get to u8channelid=10 directly in the paycallback of the payment callback method in the UC channel. Then, you can get the channel data directly and get the corresponding configuration data. Fortunately, this approach is entirely feasible. We use the Java EE (SSH2 framework) to implement the U8server, only need to integrate a tuckey urlrewritefilter to complete such a URL rewrite. The use of the plugin is very simple, the site is very detailed, not much to say. Here are just two points to note: 1, when configuring Urlrewritefilter in Web. XML, configure it before struts2 filter, otherwise the URL rewrite is invalid 2, In Struts2 's filter-mapping, add Dispatcher's statement: <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> Then, configure the rewrite rule regular expression that we need in urlrewrite.xml to: < rule> <from>^/(. *)/paycallback/([0-9]+) </from> <to>/$1/paycallback? u8channelid=$2</to></rule> now accesses these addresses: Http://192.168.1.88:8080/uc/payCallback /10 http://192.168.1.88:8080/downjoy/paycallback/11 http://192.168.1.88:8080/anzhi/ Paycallback/39 will become the following form: http://192.168.1.88:8080/uc/paycallback?u8channelid=10 http://192.168.1.88:8080/downjoy/paycallback?u8channelid=11 http://192.168.1.88:8080/anzhi/ paycallback?u8channelid=39 in this way, all channels of the payment callback address is unified, all of the following form: http://{host}/{channel}/ paycallback/{channelid} here, by the way. Before and many children's shoes communication, found that%80 above the client SDK access to students, are only concerned about the SDK client access, server-side access, no knowledge, also reluctant to start thinking and research. Although, may not need you to do server-side, but to understand the server-side access principle, for the SDK access, can cultivate a good bigger picture. The SDK access itself is not difficult, but to be efficient, concise, easy to expand and maintain still need to spend a bit of thought. (Before a friend's game company recruitment specializing in the SDK access to the technical director, monthly salary of 30K, you ask yourself, can you do? Hope that the students who are working on the SDK will understand this early.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Teach you how to quickly and efficiently access sdk--server-side payment callback processing
