Multi-tender Sale
Wirecard ePOS solution provides an option to divide Sale total amount to multiple payment transactions.
Example
Jeans in value of 100 € are paid by two payment transactions: 60 € is paid by card and 40 € is paid in cash.
Note
In payment industry domain terms multi-tender, multi-payment and split-payment can be considered as synonyms.
Why Wirecard ePOS provides multi-tender?
Merchant is able to increase its revenue as the likelihood to reach more end-consumers is increasing with more payment options provided.
End-consumers may want to combine multiple debit and/or credit cards, especially in case of purchase in value of several thousand euros which exceeds limits on their cards.
How to integrate multi-tender?
As long as you send "multitender"
field set to "true"
, you are integrated.
Warning
It is strongly advised to send "multitender": "true"
in all requests with "operation" : "PURCHASE"
. Otherwise you are not compliant with the latest Sale lifecycle model, which is described in this guide.
How to divide total amount into multiple payments?
Let's see real-live example below.
Example
Purchase of merchandise in value of 1000 EUR is paid by combining two payment methods, Alipay and cash.
1. step - Purchase operation:
Request includes mandatory fields for "PURCHASE"
operation.
However, in this case, total amount is 1000 and Alipay purchase transaction amount is 700.
POST https://switch.wirecard.com/mswitch-server/v1/sales { "multitender": "true", "operation" : "PURCHASE", "totalAmount" : 1000, "currencyCode" : "EUR", "payments" : [ { "paymentMethod" : "ALIPAY", "transactionType" : "PURCHASE", "amount" : 700, "consumerId" : "28050011747660761" } ] }
2. step - Reference Purchase operation:
Reference Purchase operation includes only reference to original Sale-Purchase and payment-specific information. In this case, cash purchase transaction covers all unpaid amount, exactly 300.
POST https://switch.wirecard.com/mswitch-server/v1/sales { "operation" : "REFERENCE_PURCHASE", "originalSaleId": "5d01cf38548f4007962e7d68004fcc76", "payments" : [ { "paymentMethod" : "CASH", "transactionType" : "PURCHASE", "amount" : 300 } ] }
What is Sale lifecycle model?
Every PURCHASE operation, which passes validation, creates new Sale-Purchase record in Wirecard ePOS system. Sale-Purchase record gets one of the following states:
- IN_PROGRESS - internal state
- UNCONFIRMED - purchase transaction is processed and Sale total amount is not fully paid
- COMPLETED - sum of completed purchase transactions cover Sale total amount
- RETURNED - all purchased goods have been returned by customer and Sale total amount is refunded
- PARTIALLY_RETURNED - only some of purchased goods have been returned by customer and part of the Sale total amount is refunded
- CANCELED - all purchase transactions are reversed and CANCEL operation was successful
- FAILED - all purchase transaction are either in FAILED or REVERSED state and FAIL operation was successful
Tip
Use GET /v1/sales/{id} call to get Sale record with all details.
What is Cancel operation?
CANCEL operation is used to change Sale-Purchase from UNCONFIRMED state to CANCELED state. CANCEL operation is accepted by system as long as all purchase transactions are in REVERSED state.
In order to move Sale-Purchase to CANCELED state, make a POST /v1/sales
call:
Request
{ "operation": "CANCEL", "originalSaleId": "bdb7dd5566f043ab9b91108863a6e833" }
"operation"
- defines type of Sale request"originalSaleId"
- identifier of original Sale-Purchase
Response
{ "operation": "CANCEL", "timeStamp": "2019-04-11T13:30:05.187Z", "status": { "code": "1000", "result": "SUCCESS" }, "id": "bdb7dd5566f043ab9b91108863a6e833", "externalCashierId": null }
"operation"
- echoed from request"timeStamp"
- date-time when response was constructed"status"
"code"
-"1000"
means operation is successful"result"
-"SUCCESS"
means operation is successful
"id"
- echoed from request; Sale-Purchase identifier"externalCashierId"
- relevant for Advanced Integration; otherwise null
What is Fail operation?
FAIL operation is used to change Sale-Purchase from UNCONFIRMED state to FAILED state. FAIL operation is accepted by system as long as all purchase transactions are in FAILED or REVERSED state.
In order to move Sale-Purchase to FAILED state, make a POST /v1/sales
call:
Request
{ "operation" : "FAIL", "originalSaleId" : "56d72f5fa5454f3e9fc8364078f74fce" }
"operation"
- defines type of Sale request"originalSaleId"
- identifier of original Sale-Purchase
Response
{ "operation": "FAIL", "timeStamp": "2019-05-22T12:07:24.857Z", "status": { "code": "1000", "result": "SUCCESS" }, "id": "56d72f5fa5454f3e9fc8364078f74fce", "externalCashierId": null }
"operation"
- echoed from request"timeStamp"
- date-time when response was constructed"status"
"code"
-"1000"
means operation is successful"result"
-"SUCCESS"
means operation is successful
"id"
- echoed from request; Sale-Purchase identifier"externalCashierId"
- relevant for Advanced Integration; otherwise null