Payment Handling: Unterschied zwischen den Versionen

Version vom 30. Mai 2018, 14:36 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

So far it is offered by two messages, the BookingRequest/Response and the dedicated payment message PaymentRequest/Response.

As the Payments elements within these two (and prospective) messages are absolutely identical, the following views are performed independently of the underlying message.

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.

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)

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.

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

Available top-level attributes

Payment Mode

FormOfPayment

PaymentAmount

PaymentServiceProvider

CashHolder

Payment Response

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

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