The request message for Confirm Funds operation The reply message for Confirm Funds operation Payment context combines with the tender type in the URI to uniquely identify a Payment Transaction for an order. Some tenders do not pass a PaymentAccountUniqueId in the payment context. Payment context without a PaymentAccountUniqueId. PayPal is one tender that does not have a PaymentAccountUniqueId for auth cancel transaction. Payment context with a PaymentAccountUniqueId. true - Attempt to perform a reauthorization if the original authorization has expired and is valid for the attempt. false - Do not perform a reauthorization, even if reauthorization is valid to attempt. A unique identifier for the request. The client is responsible for ensuring uniqueness across all requests the client initiates with this service. Allowable Values: Text string Required: No Length: 20 Default Value: blank Restrictions: N/A Aliases: N/A Payment context combines with the tender type in the URI to uniquely identify a Payment Transaction for an order. Some tenders do not pass a PaymentAccountUniqueId in the payment context. Payment context without a PaymentAccountUniqueId. PayPal is one tender that does not have a PaymentAccountUniqueId for auth cancel transaction. Payment context with a PaymentAccountUniqueId. true - reauthorization was attempted as requested for the now expired authorization false - reauthorization was not attempted due to no reauthorization being requeste, or the doriginal authorization still being valid. This xsd:any element indicates that future optional elements may show up in this location of the XML document in the responses returned from the service. The purpose of this xsd:any element is to define a more robust service interface that allows for new, optional elements to be added to the service's responses without the service clients' code throwing exceptions. The client code for this service call should be written to not break if new optional XML elements show up in this part of the service response. Modern XML marshalling frameworks often process xsd:any elements properly out-of-the-box (for example, in Java, JAXB and JibX XML marshalling frameworks both honor xsd:any elements and don't throw exceptions if new optional elements appear within the xsd:any section of the XML document). Developers' unit tests of their service client code should include a test case where this reply message contains one or more new elements in this location of the XML document. If new optional elements are added to this interface, a new schema will be created, communications will be sent out, and you will have the option to modify your service client code to process and use the new elements. If there is no need/desire to process the new optional elements, your service client should continue to run uninterrupted as long as it is built to honor this xsd:any element.