...
An element of type vct:RequestType has the following constituents:
Name | Type/occurrence | Description |
|---|---|---|
vct:BuyersID | udt:IdentifierType | Buyer's ID, e.g. customer number. |
vct:Credential | Client authorization; see below. | |
vct:TransactionID | xsd:normalizedString? | Transaction instance identifier. |
vct:IsTest | xsd:boolean? | Indicator as to whether the operation should only be performed as a test (refer to test operation). |
The definition of type vct:credentialtype appears redundant, but is chosen so as to support further authentication mechanisms (such as certificates) possibly resulting from later extensions.
Name | Type/occurrence | Description |
|---|---|---|
vct:Password | xsd:string | Password. |
Defined as a constraint of type vct:RequestType is the type vct:TransactionRequestType; the constraint dictates use of the element vct:TransactionID.
...
RequestName
BuyersID
Password
TransactionID
IsTest
Version
Further parameters might also be specified in the respective definitions of the operations. Serving as the value of each specified parameter is the content of the identically named sub-element of the respective request element, or the name of the element itself in the case of the "RequestName" parameter.
Rule: Version parameter
...
Only the following values are permissible for the version parameter: 1.0, 1.1, 1.2, 1.3.
...
Impermissible values for versions are to be ignored by the server.
...
parameter
...
The version parameter has only been introduced with veloconnect 1.3, i.e. servers which only support an older version of the specification ignore this parameter.
Servers which already support veloconnect 1.3 can use this parameter to maximize downward compatibility with clients which do not yet support veloconnect 1.3, by proceeding according to veloconnect 1.1 in an absence of the parameter version.
...
.