Payment Handling: Unterschied zwischen den Versionen

Aus DRV STRING
Wechseln zu: Navigation, Suche
Zeile 1: Zeile 1:
−
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.  
+
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 respectively. 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.
+
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.
  
 +
 +
[[Datei:Capture PaymentsRequest(Type).PNG|334px|rahmenlos|links]]
 +
 +
 +
[[Datei:Capture PaymentsResponse(Type).PNG|336px|rahmenlos]]
 +
 +
 +
In both, request and response the underlying basic structure/complex of a concrete payment is '''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 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.
 +
 +
{| class="wikitable sortable"
 +
|-
 +
! Attribute!! Values / Explanation
 +
|-
 +
| @Collection||
 +
{| class="wikitable sortable"
 +
 +
| Agency|| For agency debiting
 +
|-
 +
| TourOperator|| For tour operator debiting; i.e. the customer directely pays to the tour operator
 +
 +
|-
 +
| OnSite|| In case the payment must be made on site, e.g. a sports course offered by the hotel
 +
 +
|-
 +
| 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
 +
|}
 +
 +
|}
  
 
== Payment Request ==
 
== Payment Request ==

Version vom 25. Mai 2018, 14:54 Uhr

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.


Capture PaymentsRequest(Type).PNG


Capture PaymentsResponse(Type).PNG


In both, request and response the underlying basic structure/complex of a concrete payment is 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 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
Agency For agency debiting
TourOperator For tour operator debiting; i.e. the customer directely pays to the tour operator
OnSite In case the payment must be made on site, e.g. a sports course offered by the hotel
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

Payment Request

Capture PaymentRequest(Type).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
Agency For agency debiting
TourOperator For tour operator debiting; i.e. the customer directely pays to the tour operator


OnSite In case the payment must be made on site, e.g. a sports course offered by the hotel


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


Payment Response

As extension of the request we here have the following additional information

Capture PaymentResponse(Type).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

Von „http://string.drv.de/wiki/index.php?title=Payment_Handling&oldid=398“