Payment Handling: Unterschied zwischen den Versionen

Aus DRV STRING
Wechseln zu: Navigation, Suche
(Payment Response)
(Payments)
Zeile 40: Zeile 40:
 
Another chapter is dedicated to the different Form Of Payment (FOP)  
 
Another chapter is dedicated to the different Form Of Payment (FOP)  
  
At the end we also will present some xml examples.
 
 
   
 
   
 
 
We will start with the description of the '''@Collection''' attribute, which substantively is identical for request and response, with the only difference that it is mandatory for the response.
 
We will start with the description of the '''@Collection''' attribute, which substantively is identical for request and response, with the only difference that it is mandatory for the response.
  
Zeile 71: Zeile 69:
  
 
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.
 
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 ===
 
=== Payment Request ===
Zeile 141: Zeile 141:
  
 
[[Datei:CashHolder(Type).jpg|588px|rahmenlos]]
 
[[Datei:CashHolder(Type).jpg|588px|rahmenlos]]
 +
 +
  
 
=== Payment Response ===
 
=== Payment Response ===
Zeile 169: Zeile 171:
  
 
[[Datei:PaymentDetails(Type).jpg|369px|rahmenlos]]
 
[[Datei:PaymentDetails(Type).jpg|369px|rahmenlos]]
 
 
  
 
== PaymentOptions ==
 
== PaymentOptions ==

Version vom 31. Mai 2018, 15:28 Uhr

General information

The payment handling, provided by Payments elements, allows

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


Additionally there are further "functions" available to the Tour Operator / Organizer and thus within responses only:

  • PaymentOptions to inform about the supported Form Of Payment (FOP) and possibly associated fees (surcharges) respectively
  • PaymentOverview to present a payment summary at one glance.


So far this all is offered by two messages, the BookingRequest/Response and the dedicated payment message PaymentRequest/Response and that also the same identical way.

Therefore the following views are performed independently of the underlying message.


At first we focus on Payments, followed by PaymentOptions and PaymentOverview

Finally we will present some xml examples.

Payments

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, independent from the channel these have been entered.


In both - request and response - the underlying basic structure/complex of a concrete payment is from PaymentType, with different characteristics respectively extensions for request and response; but the basic information is always the same.

So PaymentsRequestType/PaymentsResponseType inherits from PaymentType respectively.


Further Payments always signalizes that we are dealing with one or more payments while Payment elements are used for one concrete payment respectively.


PaymentsRequest-Response.jpg


In the following we will describe the used request and response structures more in detail. However, we only will show the information that is helpful for a general understanding in the treated context “payment handling”. The complete information on all available elements, attributes, values etc. can be taken from the XSD Documentation.

Another chapter is dedicated to the different Form Of Payment (FOP)


We will start with the description of the @Collection attribute, which substantively is identical for request and response, with the only difference that it is mandatory for the response.

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.

Please notice, that this is valid for all payments of the booking as a whole.

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 encashment 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 at all 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

PaymentRequest(Type).jpg


Available top-level attributes

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

But notice, that here the attribute is attached to a concrete payment respectively


PaymentScope

This describes the purpose of the payment(s); it is an enumeration with the following values

Value Explanation
Balance This is used to mark the total price to be paid to the organizer / Tour Operator, less any down payment.

Initially, this amount is specified together with a due date by the organizer / Tour Operator.

Deposit This is used to mark the down payment amount expected by the organizer / Tour Operator, which is initially specified by them together with a due date.
Interim This is used to mark an interim payment with an amount less than the remaining payment amount when the due date for the remaining payment has not yet been reached.

So this is also used for marking installments in the case of installment payments


FormOfPayment

FOPs


PaymentAmount

PaymentAmount - CurrencyAmountType.jpg

Just to record it again, all (payment) amount fields are always formed from a decimal value and the ISO currency


PaymentServiceProvider

PaymentServiceProvider(Type).jpg

This more or less is self-explanatory.

Beside the name of the Payment/Financial Service Provider and the URL on a logo of the same also a description/explanation can be indicated herewith.


CashHolder

CashHolder(Type).jpg


Payment Response

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

PaymentResponse(Type).jpg


Here we describe only the newly added or changed elements in comparison to the request

We don't repeat the information here which is identical with the request part documented above.


Status

status information...


Dates

PaymentDates(Type).jpg


PaymentDetails

PaymentDetails(Type).jpg

PaymentOptions

PaymentOverview

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