FAQs

Q. How can I understand the sFTP flow easily?
A. Refer to the flow chart below to understand the sFTP flow: sFTP Flow

Q. What happens to a load via the sFTP process when there are not enough funds in the company’s virtual account to cover the total amount within the file?

  • For Reloadable and Non-Reloadable Reward Programs:
    • In case of insufficient funds for debiting the total value load amount, we create the order and mark the order as Pending Sufficient Funds, which can then be resumed through the Portal once the balance is updated.
    • Note: same for Reward Portal Upload
  • Corporate Payment and Purchasing:
    • For SFTP payroll load, the order goes to ‘pending sufficient funds’ status in case of insufficient funds.
    • Note: different for Payroll Portal or API load: Order gets failed directly.
  • Additional Questions about Insufficient Funds Error Handling:
    • Q: Do we look at the load total of entire file before attempting to load each card/record or do we look row by row?
    • A: We check the load total of entire file. If the load total is greater than the VA balance then we give the order status accordingly.
    • Q: Will we auto push the file once the funds are there? Or does the client need to use the portal to Resume the Load?
    • A: No, it will not be pushed automatically. Client needs to use the resume load option.
    • Q: Is the client ever notified via FTP – do they receive either a Failed or Completed file?
    • A: Client will only get the completed/failed file when the order will get completed/failed. In case of pending status, client will not get any return file.

Q. Do we process each record individually?

We check for the field validations individually, for example, Phone should be a 10-digit number, email should be in the correct format. This is done at the record level. Only the validated rows will be sent to FIS in the issuance file. Also, once the validated rows get the response, we update the response from FIS in the return file, along with the invalidated rows that were not sent to FIS.

  • If the file contains bulk shipping records and one of those records fails, then all the bulk shipping records will fail.

Q. What happens if the whole file fails?

If the file fails, we do not send the details to FIS and update the return file with errors.

Q. What do we do with files once they are processed?

Yes, we move the files to the Processed folder once the file is processed. The file is renamed with a suffix as

  • _completed – If successful, a return file is generated by suffixing “_completed” in the processed folder. The return file would have additional columns such as DDA number, proxy card number, etc.
  • _failed – If failed, a return file is generated by suffixing “_failed” in the processed folder.
  • _partiallyprocessed – If one or more card orders fail and a few are successful, the status is updated with “Partially Processed.” Two files are generated: _completed for successful orders and “failed” for unsuccessful orders.

Q. Do clients typically poll your server to see when the return file shows up?

It completely depends on the client. Some clients want to verify everything from the return file, and some verify it from the order reports in the portal.

Q. How quickly are the bulk load files processed and return files placed back in the FTP server?

It takes around 20 mins to process the files and 45 mins to get the return files.

Q. What happens if a file fails? Does the entire file fail, or only portions of it?

In case of insufficient funds, the entire file is failed (even if the amount is larger than the VA balance for a single row). In all other scenarios, it gets partially processed.

Q. What are the error messages I could receive?

Depending on the file upload, there could be any error. Refer to the error docs here for more information based on the error code.

Q. Do I need to reprocess the entire file if it fails?

Yes.

Q. Would the UAT site be more appropriate for our testing? Should our test site be pointing to this site?
Yes. https://portal-api-uat.dashsolutions.com/_ah/api/ is the base URL of UAT APIs.

Q. What is the difference between the UAT site and the production site?

UAT and Prod sites respond with almost the same results for the single operation calls. There is a difference in the case of batch (bulk operations), which is not supported by our processing platform. Only production processes the batch requests.

Q. What happens when a card maximum is exceeded?

Dash team – we won’t fail the load if the load pushes the max balance past the limit, but we will fail a load if the intended load exceeds the Max Load limit.
Eng: Based on the approach:
1. API: We fail the load with error: The maximum value load allowed on the card is .
2. SFTP (V3): We fail the load with error: Potential Value Load Amount Error.

Q. The load Card call will succeed if the card max is exceeded. Can the load card return some type of failure response instead? What does it do when the max per load amount is exceeded?

Dash team – weigh in on error responses if load value exceeds max value load limit.
Eng: Based on the approach –
API: We fail the load with the error: The maximum value load allowed on the card is .
SFTP (V3): We fail the load with the error: Potential Value Load Amount Error.

Q. What happens if we mistakenly (or legitimately) call the order card multiple times?

Dash team – didn’t we build logic for Fuego where they can pass us a unique ID to catch any duplicate orders?
Eng: Other Field configuration is at the customer program level, based on the configuration.
– API: Responds with an error.
– SFTP: Responds.