I have a question about using TMS and Controlled Batches. We don't use a lot of them, but we certainly use them for:
Does this documentation mean that until such a time as Tessitura removes controlled batches, and presumably updates the utilities that rely on them, TMS users cannot use the listed utilities?
Controlled batches cannot be used with EMV or Secure Deviceless Entry payments. If your fundraising department was using controlled batches they will need to transition to uncontrolled batches. Note: Controlled batch functionality will be removed in a future version of Tessitura. The Network recommends using uncontrolled batch types, except when a controlled batch is required for the following utilities: Contribution Import Utility, Event Cancellation Utility, On Account Funds Disbursement Utility, Direct Debit Order Billing, Direct Debit Pledge Bills, SEPA Direct Debit Order Billing, and SEPA Direct Debit Pledge Billing. https://www.tessituranetwork.com/Help_System/Content/TN-Application/Payment-Methods/TMS-Getting-Started.htm
Controlled batches cannot be used with EMV or Secure Deviceless Entry payments. If your fundraising department was using controlled batches they will need to transition to uncontrolled batches.
Note: Controlled batch functionality will be removed in a future version of Tessitura. The Network recommends using uncontrolled batch types, except when a controlled batch is required for the following utilities: Contribution Import Utility, Event Cancellation Utility, On Account Funds Disbursement Utility, Direct Debit Order Billing, Direct Debit Pledge Bills, SEPA Direct Debit Order Billing, and SEPA Direct Debit Pledge Billing.
https://www.tessituranetwork.com/Help_System/Content/TN-Application/Payment-Methods/TMS-Getting-Started.htm
X-Posted to Finance
We were told we cannot use them.
Okay…looks like I was misreading, and regular Pledge Billing is available (?), but losing Event Cancellation would be a blow. Also I'm assuming that using Contribution Import without card payments is okay.
I DM'd you.
Speaking in a very much ill-informed capacity as someone who has still not spent even a single second in V16, I recall someone saying at TLCC this year that TMS will (either currently or eventually) have solutions to get around the things that would require you to use a controlled batch by using "new tools" with an uncontrolled batch that would allow you some form of proofing or such.
I have no idea what those would be, but I know that we use controlled batches for ALL of our donation processing and our Development department loves them. So to lose them with such "new tools" I am sure would annoy them.
We only use controlled batches for non credit card transactions. You can't use them with TMS for any credit card activity, and Tessitura is recommending the discontinued use completely, although we haven't done that yet.
All the utilities that use controlled batches can be used with Tessitura Merchant Services. And that's because they are either using on-file credit card tokens or are refunding by reference number. In other words, no credit card data is being stored in the controlled batch.
Controlled batches just can't be used for order or contribution processing.
Aha, that's very good to know! Should I put in a ticket for a documentation update?
Nancy Sheleheda said:We only use controlled batches for non credit card transactions.
We have been on TMS since 10/23, and Devo staff noticed that the above does continue to work.
Well, the documentation isn't wrong currently. It says you can't use controlled batches with EMV device payments or Secure Deviceless Entry payments. And the note says you can still use them for those utilities, noting them as exceptions.
What clarification do you think would be helpful?
The sense I got from reading was that controlled batches could not be used with TMS card operations generally, and that the additional text about the eventual removal of controlled batches was unconnected general documentation on controlled batches: i.e. if you are not using TMS you should still avoid controlled batches except where used by utilities. So the line about on-file cards still being usable in controlled batches is what I was looking for.
When you say "refunding by reference number", is the Event Cancellation Utility doing that? I was under the impression that it moved all transactions to On Account first and then (I presumed) refunding to card on file.
Yes. Refund by reference number is the technical thing that happens with the Refund Prior Payments function, which is what the utility uses. Essentially it looks up the original transaction based on it's reference number in the payment processor and reverses it. Credit cards do not need to be kept on file to use that functionality.
I'll give some thought to how I can reword things in that help topic to avoid any possible confusion. Maybe breaking apart the note that controlled batches are going away from the bit about the utilities that still use them even if you are on TMS.
I think the key distinction here that Kevin mentioned is that the utilities do not use or store credit card information. In other words, they do not use any cards on file. For payments, these utilities use saved tokens only. For refunds they do refund by reference, which does not use card data either.
When I say "card on file" I mean saved token: no one has actual card numbers on file anymore, right?
Well, a token is they way the card is stored. I wasn't really referring to directly storing an untokenized card. Refund Prior Payments doesn't rely on stored accounts (tokenized or untokenized). It just references the original transaction and reverses it, all based on the the payment provider's transaction ID, or reference number. Hence the refund by reference phrase I started with back at the beginning.
I looked closer at what your post and think I slightly misunderstood when I replied last. We all mean tokenized when talking about cards on file. If a utility charges a card, it's using the tokenized card on file. If a utility is making a refund, it doesn't need a card on file, it's just reversing the transaction.