Payment Handling: Unterschied zwischen den Versionen

Aus DRV STRING
Wechseln zu: Navigation, Suche
(General information)
Zeile 4: Zeile 4:
 
* The user to enter payments  
 
* The user to enter payments  
 
* The Tour Operator to inform on expected, desired and effected payments
 
* The Tour Operator to inform on expected, desired and effected payments
This all in line with the valid data protection requirements.
+
And is offered by '''BookingRequest/Response''' and an dedicated payment message, the '''PaymentRequest/Response'''
  
  
 
With a '''request''' one might enter '''one or more payments''' whereas the '''''responses''''' will inform you on '''''all existing payments''''' (payment positions) of the "booking" at that point in time.
 
With a '''request''' one might enter '''one or more payments''' whereas the '''''responses''''' will inform you on '''''all existing payments''''' (payment positions) of the "booking" at that point in time.
  
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 extended by '''PaymentsRequestType/PaymentsResponseType''' respectively.
+
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 extended to '''PaymentsRequestType/PaymentsResponseType''' respectively.
  
 
[[Datei:Capture PaymentsRequest(Type).PNG|334px|rahmenlos|links]]
 
[[Datei:Capture PaymentsRequest(Type).PNG|334px|rahmenlos|links]]
Zeile 46: Zeile 46:
 
== Payment Request ==
 
== Payment Request ==
  
[[Datei:Capture PaymentRequest(Type).PNG|730px|rahmenlos|ohne]]
+
[[Datei:Capture PaymentRequest(Type).PNG|rahmenlos|ohne]]
 +
 
  
  
Zeile 68: Zeile 69:
 
As extension of the request we here have the following additional information
 
As extension of the request we here have the following additional information
  
[[Datei:Capture PaymentResponse(Type).PNG|685px|rahmenlos|ohne]]
+
[[Datei:Capture PaymentResponse(Type).PNG|428px|rahmenlos|ohne]]
  
  

Version vom 29. Mai 2018, 13:31 Uhr

General information

The payment handling allows

  • The user to enter payments
  • The Tour Operator to inform on expected, desired and effected payments

And is offered by BookingRequest/Response and an dedicated payment message, the PaymentRequest/Response


With a request one might enter one or more payments whereas the responses will inform you on all existing payments (payment positions) of the "booking" at that point in time.

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 extended to PaymentsRequestType/PaymentsResponseType respectively.

Capture PaymentsRequest(Type).PNG


Capture PaymentsResponse(Type).PNG


To both, the Payments and the single Payment occurrences the attribute @Collection is attached. In first case to the payments of the booking as a whole, in the second case to the single payment elements 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
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

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

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 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

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