Developer Resources

The EFTCardMod operation provides the ability to activate an EFT card, deactivate an EFT card, and modify the status of an EFT card. At a minimum, the request must include the EFTCardNum element representing the card number of the EFT card to modify. The status of the card can be modified by passing in the desired status code in the EFTCardModRec.EFTCardStat element.

The complete PassPort Card Status list is as follows:

• To activate a card, EFTCardStat should be set to a value of A (Active). When changing EFTCardStat from W (Warm Card) or H (Hot Card) the CardStatRsnType value should be cleared by setting to an empty value.
• To report a debit card lost or stolen, EFTCardStat should be set to a value of H (Hot Card).
• When changing EFTCardStat to W (Warm Card) or H (HotCard), a CardStatRsnType must also be included. This canonical is defined as one of the following ISO-8583 values:
• 05 - Do Not Honor
• 33 - Expired Card, pick up
• 34 - Suspected Fraud, pick up
• 41 - Lost Card, pick up
• 43 - Stolen Card, pick up
• 59 - Suspected Fraud

The EFTCardMod response will return an RsStat element with a value of Success if the status was modified successfully.

If the EFT card number is unknown, it can be obtained by first calling the EFTCardSrch operation and passing in the customer id and/or debit account id:

The EFTCardSrch response will contain an EFTCardSrchArray of results that match the customer id and/or debit account id in the request. Each record in the array will have an EFTCardNum element with the EFT card number. If no match is found, an array will not be returned and the response will contain a warning with an ErrCode value of 49 and ErrDesc of No Records Match Selection Criteria .

Travel Information

To update the Travel information (Start Date, End Date and Remarks), for a specific card, you will need to use the EFTCardMod message. It has three elements that support this information.

• EFTCardModRec.EFTCardTrvInfo.TrvStartDt
• EFTCardModRec.EFTCardTrvInfo.TrvEndDt
• EFTCardModRec.EFTCardTrvInfo.TrvRmk

You can find out more about this message that includes the Message Brief, Errors and the Mapping information to the core based Passport data here. You’ll need to login to the website if you aren’t already when you click the link.

One very important piece of information about the Travel elements: The FI must use JH’s Fraud Center, and subsequently PowerLink for this information to be at the Switch level. If the FI uses a 3rd party switch, the travel information is only informational, and not monitored for fraud.

Core Director Specfic Information

Here’s a breakdown of the international and travel fields that Core Director currently supports through jXchange:

• Field 259. International Flag. Field can be set via EFTCardModRec.AllowFornTrnType, where “Y” indicates to allow international transactions and “N” indicates to not allow
• Field 302. Vacation Start Date.  Field 302. Vacation Start Date.  Field can be set via EFTCardModRec.EFTCardTrvInfo.VacStartDt
• Field 303. Vacation End Date.  Field can be set via EFTCardModRec.EFTCardTrvInfo.VacEndDt
• Field 301. Vacation Details.  Field can be set via EFTCardModRec.EFTCardTrvInfo.VacRmk
• Field 298. Travel Start Date.  Field can be set via EFTCardModRec.EFTCardTrvInfo.TrvStartDt
• Field 299. Travel End Date.  Field can be set via EFTCardModRec.EFTCardTrvInfo.TrvEndDt
• Field 297. Travel Details.  Field can be set via EFTCardModRec.EFTCardTrvInfo.TrvRmk

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SOAP-ENV:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
      <wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
        <wsse:Username>{Insert}</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{Insert}</wsse:Password>
        <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"/>
      </wsse:UsernameToken>
    </wsse:Security>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <EFTCardMod xmlns="http://jackhenry.com/jxchange/TPG/2008">
      <MsgRqHdr>
        <jXchangeHdr>
          <JxVer></JxVer>
          <AuditUsrId>{Insert}</AuditUsrId>
          <AuditWsId>{Insert}</AuditWsId>
          <AuthenUsrId></AuthenUsrId>
          <ConsumerName></ConsumerName>
          <ConsumerProd></ConsumerProd>
          <Ver_1/>
          <jXLogTrackingId>{Insert}</jXLogTrackingId>
          <Ver_2/>
          <InstRtId>011001276</InstRtId>
          <InstEnv>TEST</InstEnv>
          <Ver_3/>
          <BusCorrelId></BusCorrelId>
          <Ver_4/>
          <WorkflowCorrelId></WorkflowCorrelId>
          <Ver_5/>
          <ValidConsmName>{Insert}</ValidConsmName>
          <ValidConsmProd>{Insert}</ValidConsmProd>
          <Ver_6/>
        </jXchangeHdr>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </MsgRqHdr>
      <ErrOvrRdInfoArray/>
      <EFTCardNum MaskVal="431123******7860">4311230036277860</EFTCardNum>
      <EFTCardModRec>
        <EFTCardStat>A</EFTCardStat>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
        <Ver_4/>
        <EFTCardTrvInfo>
          <TrvNotType JHANull="" Rstr=""></TrvNotType>
          <TrvStartDt JHANull="" Rstr="">2019-06-02</TrvStartDt>
          <TrvEndDt JHANull="" Rstr="">2019-07-15</TrvEndDt>
          <TrvRmk JHANull="" Rstr="">Hawaii</TrvRmk>
          <Ver_1/>
          <VacStartDt JHANull="" Rstr="">2019-06-02</VacStartDt>
          <VacEndDt JHANull="" Rstr="">2019-07-15</VacEndDt>
          <VacRmk JHANull="" Rstr="">Aloha</VacRmk>
          <CardHolderConFraudType JHANull="" Rstr="">true</CardHolderConFraudType>
          <Ver_2/>
        </EFTCardTrvInfo>
      </EFTCardModRec>
    </EFTCardMod>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Q: Is it possible to call EFTCardMod - or another method exposed by any jXchange service - to update PIN offset of an EFTCard?

A: First of all, there is no API to change the actual PIN for a debit card. The only thing that Jack Henry (CPS) stores in the database is the PIN Offset that was calculated from a new PIN. However, to change the PIN offset you would need to have some sort of device (usually an instant issue machine) to calculate the offset. This device would have keys stored on it that refer back to the ISO and PIN encryption, which if setup correctly can use the card number, PIN number and the keys to calculate the new offset. Once that new offset is created it can then be updated using the EFTCardPINOffSetId element that you found in the EFTCardMod service.

Q: What is EFTCardProdCode field used for?

A: The EFTCardProdCode field is used to detail what type of card the FI has setup and issued. The type of card is determined by the first 6 digits, called the BIN/ISO number. Since it is FI independent, the ParmValSrch function, with the element ParmName set to EFTCardProdCode, will return all the BIN/ISO numbers setup at an FI.

Q: Is it possible to put spending limits on a card? For instance can we say that even though a DDA has $1000, a card is only allowed to spend $200?

A: With regards to your original question about setting an overall spending limit on a card, the Passport team got back to us and confirmed that the only limits that can be set are daily limits. The daily number of transactions can be set using EFTCardModRec.EFTTrnLmtCnt, while daily dollar amounts can be set up on each card using EFTCardModRec.ATMDrPostLmtAmt for Withdrawal Limit and EFTCardModRec.POSDrPostLmtAmt for Point of Sale Limit. The overall withdrawal or POS is the actual daily limit set on a card, so if the POS limit is $200 then you can do any number of transactions until it reaches $200 or until you reach the transaction count limit.

There are also temporary withdrawal and POS limits. These are the limits that would normally get changed. If the limit needs to change for a certain reason then the temporary limit can be changed with a start date and end date to make it temporary. This is normally used when a cardholder is traveling and needs a higher limit or a cardholder that needs to make a purchase that is higher than their normal daily limit. The elements needed for this use case are:

EFTCardModRec.ATMDrTempPostLmtAmt
EFTCardModRec.ATMDrTempPostStartDt
EFTCardModRec.ATMDrTempPostEndDt
EFTCardModRec.POSDrTempPostLmtAmt
EFTCardModRec.POSDrTempPostStartDt
EFTCardModRec.POSDrTempPostEndDt

Q: I would like to understand what each possible status means and whether it’s valid. Some of them seem obvious (e.g. “Act” is for active cards) but I’d rather not assume. Also, some, such as “Iss” for issued, that seem obvious are not valid.

A: Please refer to the EFTCardAdd FAQ.

Q: The FI needs to reissue a card for a customer due to damage, but the customer would like to keep the same number and expiration date. How do we do it?

A: It can be accomplished simply by calling EFTCardMod with EFTCardStatType set to ‘ReOrderCard’. This would reissue the card with the same card number and PIN offset. The expiration date is handled a little differently though, if the card is going to expire in less than a year it will go ahead and bump out the expiration date, otherwise if it’s more than a year it will keep the same expiration date.

Q: What API call should be used to order a replacement card?

A: For debit cards this would be EFTCardMod and set <EFTCardStatType> to ‘OrderCard’ or ‘ReorderCard’. For credit cards see the CrCardRptLostAdd operation under the PSCU CDE Translator provider.

Q: For SilverLake, in the EFTCardMod operation, what are the possible IDs for the EFTMerId? I believe these are suppose to the Opt-In Merchant IDs. What are the possible merchant IDs?

A: EFTMerID is to opt a card in or out for VAU/ABU updates. The values are Y, N, blank, or null. However this field really does nothing. The FI has to maintain this field somewhere else.

Q: While adding a travel notification with a phone number we are getting the error message "Message not defined". What does this mean?

A: The TrvPhoneArray is not currently supported via a jXchange operation and can only be updated via Xperience SilverLake or the SilverLake core screens.

Q: Is there a way to add multiple travel notifications for a single debit card?

A: Unfortunately no, there is not a method to add multiple travel notifications for a single card.

Q: Is there a way to delete a travel notification for a debit card and how we will do that?

A: There is not a method to delete a travel notification via a jXchange operation. The FI would have to let the notification expire or go into the Quick Assist screens directly and remove the notification.

Q: What status do I use to mark the card as frozen due to potential loss or other factor?

A: The Warm card status will freeze the card to only allow deposits. This state can allow card to be reactivated later.

Q: What status do I place a card into if the card is stolen or truly lost so it can be permanently frozen for reissue?

A: The card should be placed in Hot Card status. A Hot Card should be reissued if the customer request a new card.

Q: Can you please describe the purpose of the SilverLake EFTCardMod method's CardStatRsnType value?

A: Hot Card – This will disable the card from working on the host system.  It will also generate a 302 iso8583 message that will get sent out to the switch as well at the networks and disable the card there.

Warm Card – This will disable the card with the exception of deposits.  It will generate a 302 iso8583 message that will get sent to the switch however it will not go out to the Networks.

Here are the codes and statuses that should be in with the status.  The ones most commonly used would be 05 for Warm Card and then 41 and 43 for Hot Card.

• (05) - Warm Card -   Do not honor.
• (59) - Warm Card -   Suspected fraud.
• (33) - Hot Card -  Expired card, pick-up.
• (34) - Hot Card -  Suspected fraud, pick-up.
• (36) - Hot Card -  Restricted card, pick-up.
• (37) - Hot Card -  Card acceptor call acquirer security, pick-up.
• (41) - Hot Card -  Lost card, pick-up.
• (43) - Hot Card -  Stolen card, pick-up.

Q: Can you add a travel notification on a check card? If so, what fields does jXChange use to complete the action?

A: To update the Travel information (Start Date, End Date and Remarks), for a specific card, you will need to use the EFTCardMod message.  It has three elements that support this information.

• EFTCardModRec.EFTCardTrvInfo.TrvStartDt
• EFTCardModRec.EFTCardTrvInfo.TrvEndDt
• EFTCardModRec.EFTCardTrvInfo.TrvRmk

One very important piece of information about the Travel elements is that FI's must use JHA’s Fraud Center, and subsequently PowerLink for this information to be at the Switch level.  If a FI uses a 3rd party switch, the travel information is only informational, and not monitored for fraud.

Q: How do you assess a fee for a card reorder?

A: EFTCardMod has a field mapped to “Card Reorder Fee”, EFTCardReorderFee. It is a fee for reordering the same card number. This is normally used when a customer breaks their plastic and needs a new one. The FI can set up a default fee on the CPS side for this. The EFTCardReorderFee would override the default that the FI already has set up. It is to be used when the card status is changed to R (EFTCardStat = ReOrderCard). The fee will be charged to the primary account associated with the debit card.

Q: How do I update the address for an EFTCard?

A: All addresses for the EFTCards are held on the core side on the CIF (Customer Record) except for the card alternate address (The address entered as part of the EFTCardMod API). It’s sole purpose is to override the CIF addresses in order to mail the card somewhere else. It is only a temporary address and has an expiration date. (EFTCardModRec.EFTCardMailAddrInfo.ExpDt).

Q: The "Operation Summary" has card statuses like “A” for active, “C” for closed. However, under “Message briefs”, the list of statuses is longer and the values look like “Act” and “Cls”. Which ones should I expect?

A: EFTCardStat was set to be deprecated a couple of years ago and replaced by EFTCardStatType, but the Passport services still support both elements so you can set card status using either EFTCardStat or EFTCardStatType for your EFTCardAdd/Mod requests.

Q: I would like to understand what each possible status means and whether it’s valid. Some of them seem obvious (e.g. “Act” is for active cards) but I’d rather not assume. Also, some, such as “Iss” for issued, that seem obvious are not valid.

A: Here are all the canonical values along with their mapping and description for EFTCardStatType, note that Iss is not mapped and therefore can be ignored:

Here are EFTCardStat canonical values and descriptions:

A – Active
C - Closed
D - Deleted - Cards with a status of D will be deleted from the ATCARD file during nightly processing, and all non-JHA entries will be removed when all transactions have been purged from the ATM transaction history.
E - Expired
H - Hot Card - Hot Card status will send out a message to the switch/network. Once you hot card a debit card, it is not recommended to re-activate the card. A reverse hot card message will be sent to the switch/network. However, not all networks update their files in a timely manner and could cause your cardholder problems.
I - In Process Card Order - This status means that the card was ordered and needs to be activated. The I is changed to an A (Active) once a PIN based transaction is performed with that card.
L - Limits - The approval will be based on a defined limit and not on the amount in an account.
M - Manual Activation and PIN - Customers are required to call the institution to have their new cards activated before they can use them.
O - Order New Card
P - PIN Mailer - This means that a new pin has been requested. This does not order a plastic. It only orders a new pin. The PIN Mailer process is just taking a snap shot of the current offset setting and securely translating it to the actual PIN for the customer. The PIN Mailer does not change the PIN in any way. It is more of a reminder of what the PIN currently is.
R - Re-order Card - In this status, pinned and signature transactions are approved.
S - Securomatic (after-hours depository) deposits only
W - Warm Card - Cards with this status will be blocked from making monetary transactions. The cardholder will be able to make deposits, transfer funds, and complete balance inquiries. The ATM will not capture the customer’s card. The warm status is listed on the PPCF (jhaPassPort Card File) sent to the server.
X - Exceeds PIN Attempts
Z - Not Reordered - The Z status prevents a card from being reordered if it is getting ready to expire.