tr_pmt_method_group and payment express

We weren't using Merchant ID's in tr_pmt_method_group, but were using them for grouping tr_payment_method entries.  Now we're moving to Payment Express and tr_pmt_method_group entries need a Merchant ID, but the some of the groups contain payment methods with different Merchant ID's.  For example: Payment Method Group 26 is composed of Payment Methods  Box Office and Web, but the Merchant ID for Box Office is 999 and the Merchant ID for Web is 888.  So what do I put in as the Merchant ID for Payment Method Group 26?  999 or 888?  Does it really matter?  Or do I need to create separate Payment Method Groups?

Any help would be appreciated.

Parents
  • We just moved from Transcend to Payment Express and the merchant ID’s are blank in the TR_PMT_METHOD_GROUP table.  They were always blank.  Our merchant numbers are set up in Campaigns, References, Payment Methods.   Not sure if this helps, or hurts! J
    …Dave
     
  • Per Tessitura, in case you wanted to know "You must have a merchant Id listed in TR_PMT_METHOD_GROUP. This Merchant ID is necessary for when a token is created outside of a payment, such as non-payment tokens like tokenizing old cards,  adding a card to a payment schedule, adding a card to a constituent account. If the token comes from a payment, the merchant ID comes from the payment method."

  • when a token is created outside of a payment, such as non-payment tokens like tokenizing old cards

    I actually created a specific group, "Converted Cards", for that specific purpose.  Then I created groups of the format "[Organization] P2PE" for all other card entry.

  • Thanks Gawain.  That is interesting.  Are you a consortium btw?  So you did it when you tokenized old cards, if you are a consortium, what happens when that card is used for a an actual payment with a merchant ID that wasn't set to the same one in the pmt_method_group when you tokenized?  Does it just go through using the merchant ID for the payment_method rather then the pmt_method_group?  Thanks again.

  • We are not a consortium, strictly speaking, but have two business units.  Those units have different merchant IDs, hence the separate groups.  We also have a third merchant id for web transactions (actually, the default group), which the two units effectively share.

    And now I'm getting into trouble: I do remember that there was something tricky involving the merchant ids attached to pre-existing cards before and after conversion, but I don't remember all the wrinkles.  What I do know is that the converted card payment method group has the same merchant id as the default group.

    The converted card group has just been helpful for me in sorting out issues as we have worked our way into tokenization.  Presumably, after a couple of years of purging expired or not recently used cards, none will be left from the conversion.

Reply
  • We are not a consortium, strictly speaking, but have two business units.  Those units have different merchant IDs, hence the separate groups.  We also have a third merchant id for web transactions (actually, the default group), which the two units effectively share.

    And now I'm getting into trouble: I do remember that there was something tricky involving the merchant ids attached to pre-existing cards before and after conversion, but I don't remember all the wrinkles.  What I do know is that the converted card payment method group has the same merchant id as the default group.

    The converted card group has just been helpful for me in sorting out issues as we have worked our way into tokenization.  Presumably, after a couple of years of purging expired or not recently used cards, none will be left from the conversion.

Children
No Data