Payment Handling: Unterschied zwischen den Versionen
| Zeile 34: | Zeile 34: | ||
|- | |- | ||
| − | | Mixed|| Signals that the Tour Operator excepts any encashement method, which here - for a concrete payment - must not be entered | + | | Mixed|| Signals that the Tour Operator excepts any encashement method, which here - for a concrete payment requested - must not be entered. But of course in an according response it might be an important information |
|} | |} | ||
| Zeile 47: | Zeile 47: | ||
| + | === 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. | ||
Version vom 25. Mai 2018, 13:36 Uhr
With payments there is meant to inform on expected, desired and effected payments AND to enter payments; this all in line with the valid data protection requirements.
Whereby with a request one might enter payments whereas the responses will inform you on the status of the payments respectively.
Inhaltsverzeichnis
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 | Beispiel | ||||||||
| @Collection |
|
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
