SynchronizePayments Method

Synchronizes bills paid on the client side with paid bills on record on the server side.

Object Oriented Interface

public function doSynchronizePayments($token);

Procedural Interface

inebank_billpayment_do_synchronizepayments($res, $token);

Remarks

The bill payment synchronization request (as all other bill payment requests: add, modify, cancel) is applicable for bank accounts only and not for the credit card accounts.

Users of OFX Payments need to be able to obtain the current status of transactions previously sent to the server for processing. For example, once the user schedules a payment and the payment date has passed, the user might want to verify that the server made the payment as directed. Additionally, OFX allows for interactions with the server through multiple clients. This means, for example, that the user can perform some transactions from a home PC and others from an office computer with each session incorporating the activities performed on the other. In order to accomplish these tasks, the user has to submit a synchronization request by calling SynchronizePayments method to insure that it has an accurate copy of the server data that is relevant to the client application. The intent of this request is to address three scenarios in which the client might lose synchronization with the server:

• A transaction has changed its state based on processing actions on the server. For example, a scheduled payment has passed its due date and has been paid or rejected.
• Transactions relevant to the client's application state have been added, deleted, or modified by a second client. For example, a user might enter or change transactions from more than one PC or application.
• A communications session between the client and server was interrupted or completed abnormally. As a result the client does not have responses from the server indicating that all the transactions were received and processed.

If this request is submitted for the first time to the server, the Token parameter has to be 0. In this case, servers should send all available history, allowing a new client (for example) to know about work done by other clients. If a user's account has never been used with OFX, the server returns no history.

Unless the synchronization is a refresh request (see below), in all subsequent requests, this has to be the previous value of Token this method returned (i.e., received for this type of synchronization request from the server). This will serve as the user's own endpoint. When the server supplies a response, it supplies a new endpoint (Token) as well. A token needs to be unique only within payments for the specified account.

A brand new client, or a client that lost synchronization, might want to learn about in-progress payments by submitting a synchronization refresh of the payment requests (i.e., wants a set of changes, rather than asking the server to send everything it knows). It would almost certainly want to do a synchronization refresh of the recurring payment models, because these often live for months or years.

A client can request a refresh of current state by calling the SynchronizePayments where Token parameter is set to REFRESH (not case sensitive). The response will reflect the current state. For example, if you create a payment and then modify it three times, even if this history would have been available for a regular synchronization, on a synchronization refresh request the servers should only send a single add that reflects the current state.

The following properties have to be set when this method is called:

Upon a successful reply, if the response contains payment aggregates, then the SyncPayments property will be populated and SyncPayments event will be fired for each payment transaction. A single payment has a single PaymentId, but it can undergo several state changes over its life and thus might have several entries in the token history.