synchronizePayees (method)

Synchronizes payees on the client side with payees on record on the server side.

Syntax

- (NSString*)synchronizePayees:(NSString*)token;
public func synchronizePayees(_ token: String) throws -> String

Remarks

Users of OFX Payments need to be able to obtain the current list of payees stored on the server that is configured for use in payments. In a "pay some" system, users are sometimes required to explicitly configure the payees to whom the system will make payments. This can be done by means of a telephone call to the payments provider or through other methods such as AddPayee or PayBill. It is only necessary to enter each payee once. In other systems, the payments provider can elect to store a list of all payees that the user has paid. This is a convenience to the client. It allows payees set up on one client to be accessible from a user's other clients. In this case, payee list synchronization provides a way for the payee to become accessible to the client software when the FI completes the setup.

The list can contain payees with or without payee IDs. An important function of the payee list is to communicate payee changes from the server to the client. This includes changes in processing date parameters and conversion of a payee to a standard payee.

Once added to the list, the payment system makes payments by the payee list ID. This makes it clear to a client when the user is adding to a payee list, and when he or she modifies an existing payee on the list. Although the messages make it clear whether a client is trying to add a new payee, a careful server will check for exact matches on payee adds and not create new payee list entries unnecessarily.

"Pay-any" systems can perform background processing that matches billing addresses with standard payees. When this occurs the server can update the relevant payee lists, and update the clients when they synchronize with the modified list data. Each payee entry in the list can also include a list of the user's accounts with that payee. This further reduces the data entry required by a user to make a payment, and facilitates the implementation of lightweight clients.

In order to accomplish these tasks, the user has to submit a synchronization request by calling SynchronizePayees 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 the following scenarios in which the client might lose synchronization with the server:

  • Payees 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 payees 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 payees 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 mot recent payee list by submitting a payee synchronization refresh (i.e., wants a set of changes, rather than asking the server to send everything it knows).

A client can request a refresh of current state by calling the SynchronizePayees method, where Token parameter is set to REFRESH (not case sensitive). The response will reflect the current state. For example, if you create a payee 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.

If the response contains a list of payees, then the SyncPayees property will be populated and SyncPayees event will be fired for each payee. A single payee has a single PayeeId and/or PayeeListId, but it can undergo several state changes over its life and thus might have several entries in the token history.

Copyright (c) 2021 /n software inc. - All rights reserved.
IPWorks OFX 2020 iOS Edition - Version 20.0 [Build 7941]