Batch Uploading & Processing

Resources

• Unified File Template Spec
• Logical Flow

Batch Processing Overview

Dash Batch Processing allows clients to submit large volumes of card orders and loads asynchronously via secure sFTP using a unified .csv template. Batch processing is asynchronous and returns results in two distinct response waves. Understanding this two‑wave model is critical to correctly interpreting response files and status suffixes.

Two‑Wave Processing Model

Wave 1: Pre‑processing (File‑Level Validation)

Pre‑processing validates the structure and integrity of the uploaded file before any records are sent to downstream processors.

Pre‑processing validates:

• File format and encoding
• Template structure and column order
• Required fields
• Duplicate file detection (based on filename)
• Basic record‑level validation

Pre-processing tasks are handled by Dash to prepare and validate the file before further processing.

• File Pickup and Validation:
  • Dash automatically picks up the file every 5 minutes for processing and validation.
    • If Validation is Successful:
      • The file is routed to the appropriate landing zone based on size and traffic:
        • Files with 4000 or more records are dropped in Landing Zone 3.
        • Smaller files are dropped in Landing Zone 1 or 2.
      • The status updates to “File Uploaded”.
  • If Validation Fails:
    • The file is placed in the processed folder with one of the following suffixes:
      • _Failed_: Indicates overall file failure.
        • Typical Scenarios
          • The template contains card loads, and there are not enough funds in the Virtual Funding account
          • The template is set up as “BulkShip”, all going to the same address, and if one record fails, we will fail the entire file
        • _Duplicate_: Indicates duplicate records.
        • _Invalid_: Indicates the file could not be parsed
        • _PartialProcessed_: Indicates partial validation success.
          • If a combination of failed and successful records is contained in a template.
            • A _PartiallyProcessed_ file that contains all records in the original file, and also indicates which records failed.
            • The successful records will be passed to Post-Processing

Wave 2: Post‑processing (Record‑Level Execution)

Post‑processing executes individual records that passed pre‑processing validation. This includes actions such as:

• Card ordering
• Card registration
• Card loading

Post-processing tasks are managed by the processing platform to complete order processing and deliver record‑level results, including both successful and failed records from the same batch file.

• File Processing at the Processing Platform:
  • Once a file is successfully routed to the processing platform, further validation and order processing begin.
    • Successful Processing:
      • If any records are processed successfully:
        • A return file is generated with the suffix _Completed_ and placed in the processed (or completed if configured by the customer) folder.
        • Additional columns such as DDA number, proxy card number, etc., are included in the return file.
        • Fetch PersonID, Exp Date, DDA, and TRN from the processing platform and store on the Dash.
        • Results are updated on the Dash portal, and the status changes to “Completed”.
      • If any records fail:
        • A return file is generated with the suffix _Failed_ddmmyyyy_hhmmss and placed in the processed (or failed if configured by the customer) folder.
        • If all records fail:
          • The status updates to “Failed”.

Note: Post-processing results may take some time to reflect on the Dash portal.

Batch processing via sFTP– Two-Wave Model