Work In Progress

Merging of old mapping in progress as well.

qbo.Tempus Services

Hanging services off of Debt for now.

qbo.Tempus services make use of 0-N TRANSACTIONTYPE Tempus calls.

qbo.Tempus ServiceName	Status	Description
RegisterDebitCard	Untested	Takes the card details and ContactID of the to-be parent Contact, verifies card is Debit with GetBinDetails, initializes a new PaymentMethod object and passes its generated ID as REPCUSTID in a call to REPADDDATA, and if the REPADDDATA was successful, saves the returned REPTOKEN in an object subscription tied to the new PaymentMethod, and finally saves the PaymentMethod itself. Currently doesn't use CVV in accordance to the Repository documentation on hand, but the Card documentation requires a CVV for a one time payment when swipe data is not present, so likely required for this as well.
DeregisterDebitCard	Untested	Takes a PaymentMethodID, verifies the PaymentMethod object exists and has a REPTOKEN object subscription, calls REPDELETE, and if successful deletes the related PaymentMethod and subscriptions.
AuthorizeRegisteredDebitCardPayment	Result mapping logic unknown	Takes a PaymentMethodID and AuthorizationAmount, verifies the PaymentMethod object exists and has a REPTOKEN object subscription, calls CCAUTH and if successful, we cannot save a new Payment child to the PaymentMethod used because the Payment table is coupled with, and requires a PaymentSchedule.
AuthorizeOneTimeDebitCardPayment	Result mapping logic unknown	Takes card information, calls CCAUTH, and if successful... does what?
GetRegisteredCard	Untested	Takes a PaymentMethodID, verifies the PaymentMethod object exists and has a REPTOKEN object subscription, calls REPLOOKUP, and if successful returns the XML details of the card. REPLOOKUP details contain a sanitized PAN for safety.
GetBinDetails	Untested	Takes a BIN/IIN number between 6 to 8 digits long, and calls GETBINDETAIL with this number, and returns the XML results of the BIN details.
ReverseDebitCardPayment	Result mapping logic unknown	Takes a SYSTEMCODE**?** and calls CCREVERSE, and if successful... does what?
VoidDebitCardPayment	Result mapping logic unknown	Takes a SYSTEMCODE**?** and calls CCVOID, and if successful... does what?

Key Mappings

The design relationship between REPTOKEN/CUSTIDENT and SYSTEMCODE/TRANIDENT seems to relate to 'our references' vs 'their references', so it would seem best to store both. A primary use case is described in the Tempus documentation in relation to TRANIDENTGUID's, "TRANIDENTGUID is especially useful in maintaining transaction integrity. In the event that your point of sale system experiences a disruption leading to a transaction being in an unknown state (i.e. network timeout, cable disconnect, system crash, exception parsing, etc…) it is best practice to initiate [a reversal with the TRANIDENTGUID] request immediately to ensure funds were not captured."

Tempus Term	Mapping Notes
REPTOKEN	Returned from REPADDDATA on success. 1-1 relation to a PaymentMethod. Currently saved as an object subscription. If a PaymentMethod has a REPTOKEN object subscription, then the PaymentMethod represents a saved entry in Tempus's repository. REPTOKENs are safe to store not encrypted: "Tempus Tokens are “Index Tokens” meaning they are not mathematically derived from the PAN. Tempus tokens are NOT one-time pads and therefore do not require secure storage nor do they put systems which handle them into PCI scope."
(REP)CUSTIDENT	The value of the new PaymentMethod's ID. Interchangeable with REPTOKEN for most calls, but most notably, it is not interchangeable when calling CCAUTH (requires REPTOKEN). This value is required when enrolling an entry into the Tempus repository with REPADDDATA.
(CC)SYSTEMCODE	Returned from a card transaction. "Unique serial number for the transaction. Usually value is numeric, may be alphanumeric. Value should be stored to later alter the transaction. Store as string". Store in/on Payment?
(CC)TRANIDENT(GUID)	The value of the new Payment's ID?. Interchangeable with SYSTEMCODE for most calls.

Tempus API

Tempus TRANSACTIONTYPE	Tempus Description
REPADDDATA	Transaction should be used when enrolling a card or check account into the repository.
REPLOOKUP	Transaction accepts a parameter of either REPTOKEN or REPCUSTIDENT to retrieve token details.
REPDELETE	Transaction accepts a parameter of either REPTOKEN or REPCUSTIDENT to remove a token from the repository.
PPCUSTADDUPDATE	Used to add or update a customer account. Updates require CUSTGUID to be passed.
PPCUSTADDCHILD	Used to add or update a child record of a customer account. Updates require CHILDGUID to be passed.
PPCUSTGETCHILDREN	Used to query all available children (Sub accounts) on a CUSTGUID.
PPCUSTADDPAYMENTCARD	Used to add or update a card payment method. Updates require PAYMENTGUID to be passed.
PPCUSTADDPAYMENTCHECK	Used to add or update a check payment method. Updates require PAYMENTGUID to be passed.
PPCUSTADDSCHEDULE	Used to add or update a payment schedule. Updates require PAYMENTSCHEDGUID to be passed.
PPCUSTCANCELSCHEDULE	Used to cancel a payment schedule. Requires PAYMENTSCHEDGUID to be passed.
PPDELETEPAYMENTMETHOD	Used to delete a payment method. Requires PAYMENTGUID to be passed.
PPGETCUSTPAYMENTMETHODS	Used to query for payment methods for a given customer. Requires CUSTGUID to be passed.
PPGETCUSTPAYSCHED	Used to query for customer payment schedules. Requires CUSTGUID to be passed.
PPREQUESTPAYMENT	Used to create a Session for a user or to send payment invitation to a user.
PPAUTHENTICATEUSER	Used to authenticate user and retrieve CUSTGUID. Requires EMAIL and PASSWORD to be passed.
PPSENDNOTIFICATION	Used to send predefined emails to users. Requires CUSTGUID and NOTIFICATIONNAME to be passed.
PPGETSESSIONVALUES	Used to retrieve predefined session variables. Requires SESSIONID to be passed.
CCTATOKENIZE	Used to get the token and related data without running a payment on a card. This data can be stored for future transaction.
CCAUTH	Used for card authorizations. Should be used in conjunction with CCAUTHTYPE.
CCCREDIT	Used to issue credits to a card. This transaction should be used to issue a credit referencing a previous transaction and therefore should use the CCLOOKUPSYSTEMCODE tag. If you choose to have your linked credits (i.e. credits issued by using a system code) limited to the amount of the initial authorization, your CCCREDIT transaction will return a TRANSUCCESS of FALSE once you have reached the amount of the initial authorization.
CCVOID	Undo a transaction prior to batch time by sending this transaction with a SYSTEMCODE. May take up to 7 business days to restore open to buy fund on the consumer’s bank account.
CCREVERSE	Undo a transaction prior to batch time by sending this transaction with a SYSTEMCODE and optionally a CCREVERSEAMT that is lower than the initial amount. A reverse should immediately restore open to buy funds in the consumer’s account as opposed to a void which may take up to 7 days. In the scenario that the consumer’s bank does not support reversals, the reverse will be treated as a void. Additional processor fees may apply.
CCRECEIPTRETRIEVE	Used to retrieve a receipt based on a CCSYSTEMCODE
CCFORCEAUTH	Used to convert a CCAUTHTYPE=AUTH transaction into a CCAUTHTYPE=SALE transaction
CCFORCE	This transaction can be used to insert a voice authorized transaction into the batch. This would be used in scenarios when the processor (i.e. FDMS, Chase, BAMS, etc…) and the Tempus gateway are unable to communicate
CCTIPADJ	Following an authorization that was ran as credit, a tip can be added to the transaction prior to settlement. This is not possible on a debit transaction.
GETBINDETAIL	Used to retrieve BIN Detail from our BIN Database supplied to us from our processing partners. Returns one or more sections in the TAG.
CCRPTUPDT	Used to update any of the stored values: TRANIDENT, STATIONIDENT, CUSTIDENT, EMPIDENT from a previous transaction. A CCSYSTEMCODE or CCTRANIDENTGUID must be used to reference the previous transaction.
CCSIGATTACH	Used to attach a Signature to a previous transaction.
CCINCAUTH	Used to increment a pre-auth. Passing a CCAUTHTYPE of AUTH will keep it in a pre-auth state. Passing a CCAUTHTYPE of SALE will convert the pre-auth record and consider it for settlement.

-------Old Mapping, delete or merge------

The Tempus Merchant Gateway plugin enables credit, debit and ACH transactions via QBO.

Payment-specific endpoints include:

Service	Endpoint	Description
CCAuthorization	Payment/CCAuthorization	Calls the Tempus CCUATH or CCCEDIT service.
CCReverse	Payment/CCReverse	Calls the Tempus CCREVERSE service to reverse a transaction.
CCVoid	Payment/CCVoid	Calls the Tempus CCVOID service to void a transaction.
CCReceipt	Payment/CCReceipt	Call the Tempus CCRECEIPTRETRIEVE to fetch a transaction receipt.

PaymentMethod-specific endpoints include:

Service	Endpoint	Description
CCSave	PaymentMethod/CCSave	Calls Tempus' PPCUSTADDPAYMENTCARD, and binds the REPTOKEN to a QBO PaymentMethod for future transactions.
CCDelete	PaymentMethod/CCDelete	Calls Tempus' PPDELETEPAYMENTMETHOD, and binds the REPTOKEN to a QBO PaymentMethod for future transactions.

PaymentMethods must be bound to a Contact-derived class (Contact, Organization, etc.) for these endpoints to work properly. This enables QBO to sync a QBO Contact record with a Tempus Customer records, so that QBO PaymentMethod records correlate to Tempus Customer Payment Method records.

Analysis of all four API documents

The Repository API is mostly deals with payment method persistence, with the addition of being able to auth a card/check. All would live in qbo.PaymentMethod with their guid REPTOKEN received when a card/check is added.

It looks as if the functionality in the Payment Portal API is mostly geared towards housing their own CRM piece, starting with creating new Customers, and including functionality like emailing a user after a payment, requesting a payment from the user, authorizing their login (that lives on their system) etc. It appears to wrap the Repository API, mostly seen in how their samples to “add a payment method for a customer” mostly mimic the Repository API sample, and importantly return REPTOKEN.

The Card (Credit/Debit/AVS) API document details three new additions to the previous two. One, extra fields and instructions on different types of cards (such as debt auth). Two, the idea of a TRANIDENTGUID (qbo.Payment) we can pass in to keep track of transactions. Three, the use of Tempus tokens; REPTOKEN is one version, but there is another seemingly more secure version called TransArmor tokens. For now, I will assume REPTOKEN is fine, and mention the other when appropriate with everyone.

The JSEncryption API has to do with a JavaScript piece provided by Tempus that encrypts everything from the front end. This document is very small, and therefore I can’t really deduce more than this. I’m sure if the requirement surfaces after everything we will get more info.

Therefore it boils down to the question, do we want to add the functionality to match our qbo.Contacts with their Payment Portal customer piece? The repository and keeping track of transactions are implementable without it especially with our PaymentMethod and related tables etc. There also exists an idea even further with customers, being able to add a PaymentSchedule.

And therefore, for whichever we decide, make a method/endpoint for each transaction type?

Terminology Mapping

QBO	Tempus	Comments
Payment	Transaction	This includes Tempus' CCAuth, CCCredit, CCReverse and related transactions.
PaymentMethod	PaymentMethod	QBO uses Tempus to store credit card numbers, and retains a token (REPTOKEN) in the QBO's PaymentMethod.AccountNumberEncrypted property.
Contact	Customer	PaymentMethods are bound to a parent record in both systems. Tempus' REPCUSTIDENT identifier will be bound to QBO's Contact record via a SubscriberID.

Key Mappings

Tempus Term	QBO Mapping
REPTOKEN	When calling PaymentMethod/TempusSave, QBO will accept credit or debit card information, pass it to Tempus' REPADDDATA service, and store the corresponding REPTOKEN in PaymentMethod.AccountNumberEncrypted. Technically, this is not an encrypted account number, but the token returned by Tempus so that QBO may remain PCI compliant.
REPCUSTIDENT	When calling Contact/TempusSave, QBO will call Tempus' PPCUSTADDUPDATE service, essentially copying QBO Contact data to Tempus.
TRANIDENTGUID	When calling Payment/TempusSave, QBO will generate a GUID to pass to Tempus' TRANIDENTGUID,and persist that same GUID to an object subscription row associated with the Payment, using the pattern www.tempusapi.com-Payment-{Guid}. This enables reconciling any payment transactions made in Tempus as a result of QBO API calls.

Repository API

Each can do either Check or Credit for each endpoint. Basic persistence endpoints. Repadddata - pass check/card info and REPCUSTIDENT, get REPTOKEN and REPCUSTIDENT

Replookup - pass REPTOKEN or REPCUSTIDENT, get card/check info and REPTOKEN

Repdelete - pass REPTOKEN, get success/fail

Ccauth/Tcauth - pass REPTOKEN and amount, get success/fail

Key Fields REPCUSTIDENT - Customer account number. Should be customer generated number unique to this card. A-Z; 0-9; .-_:/&

REPTOKEN - Used as a token lookup value. Interchangeable with REPCUSTIDENT. This is the value that is returned in a REPADDDATA

Payment Portal API

Customers can have child customers. Customers can have child payment methods. Payment methods seem to return REPTOKEN A particular Customer/Child/Payment method can have a child of Payment Schedule.

Payment method query, pass CUSTGUID get PAYMENTGUID/REPTOKEN set

Able to Authenticate User using username/password. There are more endpoints that seem related to a front end directly connected to our integration, such as session getters, requesting payment etc.

Key Fields CUSTGUID - Guid to represent the parent record of the account. PPCUSTIDENT - Merchant provided identifier to reference the account. May be used interchangeably with CUSTGUID CHILDGUID - Unique identifier for child provided by Tempus. Include this in the request to update a child record instead of create a new child record. CCACCOUNT - Stored in Tempus Technologies Credit Card Repository. Required if payment method is card. EMAIL/PASSWORD - why does this exist? TRANIDENT - Passthrough value to be tied to the transaction CUSTIDENT - Passthrough value to be tied to the transaction and customer EXTERNALCUSTIDENT - Customer identifier from third party system

Card (Credit/Debit/AVS) API

Transaction types used with a REPTOKEN, paymentguid tied to customer or the card info itself.