Payment Method Groups

In general it is a way to group payment methods in the way that they will be used (as opposed to by card type). For instance, you would want a group of payment methods that you would use for saved cards that could be used for a billing run and a payment method group for cards that are specifically used for live, in-person AMV transactions.

The are also used to assign control groups to tokenized cards. 

More information here.

I started with the documentation you linked, but I found it very vague.

I guess what I'm trying to gather is whether the grouping is for informational purposes, or whether it serves a greater functional purpose.

Could you explain to me more about the role payment method group plays in billing? Why do I want a different group for billing vs in-person? Is it just so someone knows which card to use in which scenario, or does it play a greater role in limiting which cards can be used for billing, etc?

(no further explanation needed about assigning control groups to tokenized cards-- that makes perfect sense, but is not something my org utilizes)

For us when I was at the dance company, we had multiple bank accounts.  Having a different (MOTO) Merchant ID let us tell Windcave which account to send it too. 

Merchant ID is at the Payment Group level so you set up tokenization Control Grouping at that level as well. 

In a similar way you can group Credit Card payment methods for different billing types.  In Invoice Billing Utility you select the Payment Method Group as (using my earlier example) we could do an education Credit Card invoice billing run and push those finds to MOTO Merchant ID 003 which might be the Education bank account

Speaking only for how we use them, we currently have 3 internal payment method groups and then groups for our resident companies (sub-licensees).  We have one group of payment methods for our Box Office/Development (e.g. the "in person" payment methods), another group for our payment methods that are processed online, and a third group of payment methods for our "billing" payment methods for the regular billing things we need to do (which is honestly not that much).  And, just like Heath Wilder, I am sure part of this is also related to our use of multiple Merchant IDs.  We then also have additionals for each of our sub-licensees, just to keep them separate.

We will be moving to TMS in the next 3-6 months, and it is likely many of our payment method decisions will be re-evaluated (e.g. the multiple merchant IDs), but this is where we are right now.

I am not sure that having all the groups has been specifically NECESSARY, but it HAS helped in reporting and troubleshooting.  We have a custom report for reconciliation of resident company and rental events that includes credit card processing fees which are different for different organizations.  Additionally, when trying to figure out chargeback nonsense (death to chargebacks!), it has been helpful to be able to compare online transactions to in person transactions.  But all of this is probably academic at best.

John A. Moskal II

Yep of course. It's necessary for reconciliation. Here we have 4 (Credit Card, Cash/Cheque, Gift Voucher, EFT) with only Credit Card having a Merchant ID as it's the only one taking actual transaction dollars through it.  If our EFT (EMV) was integrated, then it would also need a Merch ID. 

Are forums working again?

I did want to chime in on this topic, as I spent a lot of time (and a lot of Tessitura Support’s time) trying to figure this out for myself.

The short answer is that Payment Method Groups are largely unnecessary.  They can be used to organize groups of Credit Card Payment Methods for sorting on the Payment Methods screen or custom reporting, but they only have actual ramifications in two specific scenarios:

1. When doing a mass card tokenization operation (surely everyone has done this by now and no-one has actual card numbers in their Tessitura Database, right?), the Payment Method Group is used to assign a Merchant Id under which those cards are tokenized.  This is the only time the “Merchant Id” column in that table is used.  In all other cases the Merchant Id on the Payment Method definition itself is used.
2. If you have multiple “Saved” Payment Methods for a single card type (AMEX, etc.) that allow for billing, then you can use Payment Method Group in the Billing Utility to choose the right one.  I would guess that in 90% of scenarios, you will only have one Payment Method for any particular card type with “For Billing” checked in any particular organization.  The “Control Group” in TR_PMT_METHOD_GROUP is only used to control populating the selection menu for billing utilities or other reports that allow filtering by this field.  In all other situations the Control Group of the Payment Method definition is used, although access to use the Payment Method is controlled via Security Group settings and ignores any Control Grouping.

I had planned to make some changes to our haphazardly configured Payment Method Groups, but apparently the TMS onboarding team likes to set theirs up in a specific way, so I’m just planning to leave it until then.

I can’t remember precisely why I found it problematic, but I advise against attaching anything but the “Default Pmt Method Group” to non-credit card Payment Methods.

FYI, my email notifications still have bad urls in them (i.e. tessituranetwork.com instead of tessitura.com).

Gawain, thank you so much-- that was exactly the answer I was trying to get to.

And, as you may have guessed, I was trying to figure it out in advance of going to TMS. Someone in Development who works with billing was asking me how TMS would impact the Payment Method Groups and I didn't even know what those were to begin with.

Ok, so the TMS onboarding team on the Tessitura side has a particular way they advise to setup Payment Method Groups? And anything that's not a credit card should be set to "Default Pmt Method Group"?

Does anyone else have TMS tips around Payment Method Groups for me?

Hi Shelly. 

We have three stores in our one merchant account to capture Web, Dev/Mem, GE/Sales separately. They are defined by Merchant Ids 001, 002, 003.

The non-web store have both Saved and EMV payment methods for each credit card type.  It is important to add the IDs to the TR_PMT_METHOD_GROUP table and the Moto Merchant ID and Retail merchant ID on the corresponding payment methods.

We also use the pledge billing functionality where you select the group.  After we went live, I forgot to change that group and it tripped up our rmonthly run, so it's necessary for that process.

It can also be used for reporting, if needed.

Maybe one of our Tessitura TMS team folks could add a bit more, if there is more or if any of us are providing inaccurate info.

Thanks all!  I hope to see you all at today's community meeting.
Trini