Changelog: 2020-Jan-20

Please Note: Additional items may be appended to this Changelog in the near future once finalized.

Pushed to production :white_check_mark:, Pushed to Sandbox :beach_umbrella:.

Critical Updates

  • :white_check_mark: Users (User Passwords): Updates have been made to password resets for User Logins. New limits do not allow users to use the last 10 passwords cannot_use_old_password for their accounts.

    • If the same password is detected then an alert will be given [Error Code: 200] cannot_use_old_password -- cannot use old password. Please try a new password.
  • :beach_with_umbrella: Accounts (Duplicate Users): The Duplicate Users (duplicate_users) logic is live in Sandbox and public endpoints for Swap Users (swap_user_to_id) and Get Duplicate Users (get_duplicates) will be made available later this week. This logic closes duplicate users and prioritizes the user with the most recent account activity within an internal timeframe set by Synapse.

  • :beach_with_umbrella: Best Practices (Idempotency Keys): We have moved how we handle idempotency keys from a Redis-based implementation to a more robust DB-based implementation.

    • This has brought several improvements, including addressing a previous limitation where there was a slight delay between object creation in our Redis queue and subsequent registration of the idempotency key in our database.
      • This means, for instance, that setting a delay of ~250ms to allow a transaction’s idempotency key to register should no longer be a concern.
    • In addition, Error Status Code (”error_code”: “450”) and Error Message (”error.code”: “idempotency_key_already_used”) will no longer be used.
      • If you attempt to reuse an idempotency key, the response will instead return the object that was created when the key was first used.
    • However, please note that idempotency keys will still expire after 24 hours. Please refer to our Best Practices page for general details about idempotency keys.
  • :beach_umbrella: Native Card Issuance (Interchange Revenue): Interchange Revenue updates (to.meta.revenues[]) have been pushed to Sandbox. Each revenue object in the array will have an associated type (either type switch_fee for flat fee charged for routing transactions, or type interchange to indicate interchange revenue). For an interchange revenue object, a negative amount represents a debit and a positive amount represents a credit.

    • If type is switch_fee , the to.meta.revenues[].{}.meta field will include the meta.program field for the type of switch fee that can vary by transaction type (e.g. PIN vs PIN-less, Purchase vs Payment)
    • If type is interchange the to.meta.revenues[].{}.meta field will include the rate data for the interchange program applied according to transaction type as (meta.program), including meta.fixed_rate to indicate a fixed cost in cents, and meta.variable_rate to indicate the variable cost associated (represented in basis points). Additionally meta.cap will represent the maximum allowable value for the amount field.
      • Please note that ATM withdrawals will be represented as a fee rather than as revenue.

New Features

  • :white_check_mark: Card Issuance (Transactions): Native card transactions will now provide additional data about the likely risks associated with them and the transaction’s risk score (fraud_score).

    • Risk Reasons (fraud_score.reason) are provided to describe why the transaction was flagged.
      • Examples of codes may include SUSPICIOUS_ACTIVITY|TELECOM: Suspicious Telecom activity, or HIGH_RISK|COUNTRY: High risk country
      • Refer to Native Card Issuance Risk Reasons for a full list of risk reason codes.
    • The numerical score (fraud_score.score) will be set from 0.000 to 1.000 as assigned by Synapse’s fraud monitoring service.
      • Please note that this data is currently available as view only. More analysis will be done to improve fraud decisioning overtime.
      • Refer to View Transaction API call for Native cards for more details.
  • :beach_with_umbrella: KYC (Base Documents): Platforms can now deactivate base documents (i.e. set documents[].{}.is_active:false) when adding a document or updating the current base doc.

    • If the is_active flag for a document is set to false, it will be taken out of the list of docs used to calculate user permissions.
    • By default the base document will remain active, but can be set as active or inactive.


  • :white_check_mark: Card Issuance (Status Notes): Transaction Status Notes has been updated to include full_reversal reasons for more descriptive cases. Transactions with a status of RETURNED will also include a transaction status note in the transaction’s recent_status object, and in the last object within the transaction’s timeline [] array.

    • full_reversal: The merchant reversed the transaction without providing additional details.
    • full_reversal|customer_cancellation: The user cancelled the transaction or the merchant cancelled the transaction on the user’s behalf.
    • full_reversal|misdispense: The merchant is reversing the transaction because the user was charged or received an incorrect amount. For example, a user may try to withdraw $100 at the ATM but the ATM only has $80. A merchant may also use this reversal reason if they charged the user the wrong amount. In some cases a new transaction is created with the correct amount.
    • full_reversal|terminal_error: The merchant’s terminal malfunctioned or experienced a communication error. The terminal was unable to complete the transaction, so the merchant’s processor reversed the transaction.
    • Refer to Transaction Status Notes for more details.
  • :white_check_mark: Transactions (Merchant Profiles): Our Data Enrichment service has been updated to reflect more accurate descriptions. This information is in our ever-expanding Knowledge Repository and is returned with transactions.

    • Enrichment profile information has been changed from knowledge and is now titled enriched_info.
    • Refer to Enrichment, and View Transaction API call for Native cards for more details.
  • :white_check_mark: Client Dashboard (User Details): User Permission Codes (permission_code) have been updated to reflect more descriptive keys.

    • The KYC_FRAUD key formerly had two descriptions and use cases (blocked list KYC vs fraudulent documents detected) and will now be:
    • The UNUSUAL_ACTIVITY key formerly had two descriptions and use cases (compliance reasons vs external legal request) and will now be:
  • :white_check_mark: Client Dashboard (Node Types): Updated the list of node types that query for subnets on the individual node page.

  • :white_check_mark: Client Dashboard (Transactions): Exporting transaction data will now split “Total Fees” into “Synapse Facilitator Fees” and “Client Fees”.


  • :white_check_mark: Client Dashboard (Card Issuance): Fixed an issue where the “Ship Card” form wasn’t always displaying the last four digits of the card in the “Select Card” dropdown.