Sale Request - Alternative Payment
Currently we do support two types of Alternative Payments:
- Alipay
- WeChat Quickpay
The User Interface
The UI presents Alipay and WeChat as an alternative payment methods. At the time of payment it is necessary to select which payment method to use for settling the sale. After tapping on one of the alternative payment method it is necessary to present UI for capturing the QRCode - Alipay or WeChat as preferred by the customer.
Note
It is your responsibility to capture the QRCode and use the resulting data when adding the Alipay or WeChat payment into the Sale.
Of course, you need to create your own UI, but after that the SDK takes over. Let's see how the code is set up to handle this sale.
The iOS Object Model
The diagram below shows the key objects involved in the processing of a Alipay/WeChat sale request.
Note
The object and method names above are shown in simplified pseudo-code to make it easier to read for both developers and non-developers. Generally speaking, we remove the WDePos, which is the prefix at the beginning of all class names, and we add in some spaces. For example, the actual class name is WDSaleRequest but that is tough to read, so we display it as Sale Request instead. We do the same with method names. For example, the method add Alipay payment, shown above, is implemented in Objective-C and Swift as addAlipayPayment. The similar is true for add WeChat payment.
Info
When adding a payment method (addCashPayment, addCardPayment, etc.), you can optionally include a notification callback URL in your payment request (notifyUrl). This URL will then be called once the payment is completed, if you chose to set it.
The iOS Process Flow
The process flow in the code is as follows:
- Instantiate a Sale Request object.
- The type attribute of Sale Request defines the type of sale request, most commonly a Purchase.
- Add details to the Sale Request object with the add sale item method.
- For Alipay transactions, use the add alipay payment method.
- For WeChat transactions, use the add wechat payment method.
- Pass the full details of the Sale Request to the Payment Config object in the sale property.
At this point, the Sales Manager component has everything it needs to process the payment in the sale property, and the next steps are described in The Payment Flow chapter.
The Android Object Model
The Sales Manager component in Android is implemented as the sales() method of the EposSDK class. The Sales Builder then does most of the work as shown:
The Android Process Flow
The process flow is:
- Create an items object with a Sale Item Type of Purchase.
- Use Sale Builder to create the sale request.
- Add the sample amount (i.e., 10 €), currency and tax inclusion for the sample sale item with pay(Sales Builder).
- The add alipay payment method indicates that the full amount of the sale is paid with Alipay (i.e., 10 €).
- The add wechat payment method indicates that the full amount of the sale is paid with WeChat (i.e., 10 €). *
- A saleId string is returned which has the complete sale object.
At this point, the Sales Manager component has everything it needs to process the payment in the sale property, and the next steps are described in The Payment Flow chapter.
The Sample Code
Before jumping ahead, you should look at the sample code that demonstrates exactly how this is implemented, using the example of a single item shown in the picture of the UI.
Warning
Wechat and Alipay payments must include a sale note (only mandatory for these alternative payment methods) that can be used for storing details about the sale. While the content of this note is not validated by Wirecard (as soon as it is not empty), both Wechat and Alipay demands a brief description of the sale (ie. nature of it, or products sold) for regulatory reasons.