Payment Handling: Unterschied zwischen den Versionen
| Zeile 1: | Zeile 1: | ||
| + | == General information == | ||
| + | |||
With payments there is meant to inform on expected, desired and effected payments AND to enter payments as well; this all in line with the valid data protection requirements. | With payments there is meant to inform on expected, desired and effected payments AND to enter payments as well; this all in line with the valid data protection requirements. | ||
Version vom 25. Mai 2018, 16:28 Uhr
Inhaltsverzeichnis
General information
With payments there is meant to inform on expected, desired and effected payments AND to enter payments as well; this all in line with the valid data protection requirements.
Whereby with a request one might enter one or more payments whereas the responses will inform you on the status of the payments and that for all existing payments (payment positions) of the "booking" at that point in time respectively rather than for the latest entered payments only.
.PNG)
.PNG)
In both, request and response the underlying basic structure/complex of a concrete payment is from PaymentType, with different characteristics for request and response. To enabling the handling of more than one payment with one request/response these are provided by a PaymentsRequestType/PaymentsResponseType. In both of them and the PaymentType as well we have the attribute @Collection attached to the payments of the booking as a whole or to the single payments appearing in the request/respone.
| Attribute | Values / Explanation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| @Collection | This is used to inform on the available encashment types supported/allowed by the Tour Operator for the treated operation or the encashment type chosen by the user
|
If a Tour Operator likes to restrict the payments on a specific encashment type he can do it on Payments level; e.g.: To prohibit agency debiting he can provide "TourOperator" here, with the consequence that all payments must directly be handled between customer and Tour Operator.
In all other cases the Tour Operator can use "Mixed". The user then can decide per payment which encashment to be used, i.e. it also allows the switch of encashment types.
Payment Request
.PNG)
A brief explanation of some information displayed here
Here we show the information only which is helpful for a general understanding. The detailed information on all available elements, attributes, values etc. can be taken from the XSD Documentation.
| Attribute | Values / Explanation |
|---|---|
| @Identifier | This is a unique identifier within one message, which can be used to reference on a concrete payment |
| @Collection | Compare with explanations given above, please |
Payment Response
As extension of the request we here have the following additional information
.PNG)
A brief explanation of some information displayed here
Here we show the information only which is helpful for a general understanding. The detailed information on all available elements, attributes, values etc. can be taken from the XSD Documentation.
Furthermore we don't repeat the information here which is identical with the request part documented above.
Visualization
So we might follow the following workflow:
1. Pricing request / quote This will display the expected payments with a status "open" which at least is the total payable amount of the booking. In that case the
2. Book Within the request you can enter one or more payments With the according response one will receive back the correspondign status from Tour Operator perspective
3. Retrieve / display the booking Herewith you will receive back respectively the latest status of the (entered) payments at that time
