Home → Questions →

Can I set a memo on recurring trans?

• Edit

Frank Koehl

29 Oct, 2009 07:39 PM

Self-explanatory subject. When users view their billing history, I want to include some text describing each charge. I can set the memo field for custom transactions, but not the recurring ones. Any chance that could change?

1. 1 Posted by Frank Koehl on 29 Oct, 2009 07:49 PM

   

   Even including the Setup/Recurring Charge Code in the listed elements would be enough.

   • Edit

2. 2 Posted by Frank Koehl on 29 Oct, 2009 07:52 PM

   

   This has a lo to do with the question I asked over here. If this change in object layout impacts the data each object contains, I may be looking at this completely wrong. Instead of counting records under transactions, should I simply count each item in the charges object?

   Am I making any sense at all? :)

   • Edit

3. Support Staff 3 Posted by Marc Guyer on 29 Oct, 2009 08:16 PM

   

   Hmm.. not sure. I'll take a stab at it... If you're looking for line item detail of a transacted invoice, yeah, you can use the charges node to determine what made up the amount that was billed. The transactions node will typically only contain one transaction node. The only reason why there could be more is if a transaction failed for whatever reason and another transaction was run subsequently. There should only be one 'approved' transaction for an invoice. The memo field of a transaction is just a placeholder for information that is out of the ordinary. So, for example, if a credit is issued, the memo might say "Partial credit for invoice 1234". In other words, the transaction memo will almost always be empty.

   Presumably you know what the tracked items are so you can create your own memo field in your app if you want it to be different than the 'name' you gave CG. CG just uses the item names to describe a charge in the default invoice layout in email notifications.
   

   I hope that answers your question.

   • Edit

4. 4 Posted by Frank Koehl on 29 Oct, 2009 08:35 PM

   

   So if charges reflect what we are actually billing for, and transactions are the actual attempts at billing through the gateway, I need to be looking at charges for user display purposes. In that case, I can use the code field to determine what charges I'm looking at, and the description if one is included. Got it.

   That leaves just one outstanding problem (sorta leftover from here): how do I know know that an invoice was paid in full?

   Currently, it looks like I have to add up the values of eachAmount under charges and compare with the amount field from approved transactions.

   Is that it, or is there a better way to do this? Would it be possible for the API to include a field like paidInFull in each charges object? That would make this determinative display stuff a whole lot easier.

   • Edit

5. Support Staff 5 Posted by Marc Guyer on 29 Oct, 2009 09:18 PM

   

   Hmm... I can see how that can be confusing. To be clear, a charge type can be one of these: 'custom', 'setup', 'recurring', 'item'. If it's setup, then the code is the setup charge code. If it's recurring, then the code is the recurring charge code. If it's item, the the code is the item code. If it's custom, then the code is the code you gave when creating the custom charge. You've got it but I think this makes it even more clear.

   You can assume that an invoice is paid in full if there is a transaction with an 'approved' response and a positive amount. There can only be one of these. I just added a new node to the invoice xml called paidTransactionId. If that contains an id, the invoice is paid -- and I think it goes without saying that that id will correspond to the transaction node that paid the invoice.

   • Edit

6. Marc Guyer closed this discussion on 29 Oct, 2009 09:18 PM.

7. Frank Koehl re-opened this discussion on 30 Oct, 2009 12:34 AM

8. 6 Posted by Frank Koehl on 30 Oct, 2009 12:34 AM

   

   That's perfect! Since it's at the top level of the invoice node my parsing just got simpler (and faster), which is what CG is all about, after all.

   • Edit

9. Marc Guyer closed this discussion on 30 Oct, 2009 03:35 PM.