NCR Counterpoint to iPaaS.com Gift Card Mapping Documentation

This mapping collection brings gift cards from NCR Counterpoint into iPaaS.com for the first time. It carries the card's number and description, whether it is a gift card or a store credit, the value it was issued for, its current balance, its issue and expiry dates, its derived status, and the links back to the customer it was issued to and the transaction it was sold on.

This family does not itself carry deletions. Where a separate Delete collection exists for this entity it handles removals from Counterpoint to iPaaS.com; otherwise a removal in Counterpoint is not propagated. See NCR Counterpoint Known Limitations.

Important: these two collections operate on the same entity and share the same trigger set. They are complementary rather than alternatives, and routing between them is decided by the external-ID link, so both are normally enabled together. Subscribers or their MiSP should review both collections' filters and Add/Update settings before enabling either, and should treat NCR Counterpoint as the source of truth for gift card balances if these cards are also maintained in another connected system.

Source: GFC_NO · Destination: Number

This is a required field — iPaaS.com rejects the card without it. The gift card number as issued in NCR Counterpoint, stored there as text of up to 30 characters and always populated. This is the value subscribers and their MiSP use to identify the card in both systems, and it is what iPaaS.com stores as the card's own identifier. iPaaS.com also saves the Counterpoint gift card id as the external ID on a dedicated external-ID record, which is the primary match for subsequent updates to the same card.

Source: DESCR · Destination: Description

This is an optional field. The free-text description recorded against the gift card in NCR Counterpoint. Carried across unchanged for reference and reporting. Counterpoint stores this as text of up to 30 characters and always supplies a value, so the description always arrives and is never longer than 30 characters. Subscribers replacing this mapping with a formula are not held to that limit by iPaaS.com, but should keep results short enough to stay readable alongside descriptions that came straight from Counterpoint.

Source: (IsStoreCredit ? "Store Credit" : "Gift Card") · Destination: Type

This is a required field — iPaaS.com rejects the card without it. Allowed values: Giftcard and Store Credit. Records whether the record is a gift card or a store credit. NCR Counterpoint keeps these in two separate places, and the integration reads both into this one collection. IsStoreCredit is not a column subscribers will find in their Counterpoint database — the integration sets it while reading the record to indicate which of the two the record came from. When it is set, this mapping produces Store Credit; otherwise it produces Gift Card, which iPaaS.com accepts and normalizes to the Giftcard value. Subscribers replacing this formula should supply one of the two allowed values.

Source: return await DocumentSpacePortIdFromDocIdAsync(ORIG_DOC_ID); · Destination: TransactionId

This is an optional field that references the iPaaS.com transaction id. Links the gift card back to the transaction it was sold on. The formula takes the originating Counterpoint document and looks up the matching transaction already transferred into iPaaS.com. If that transaction has not been transferred — or the card was not issued against one — the mapping resolves to empty and the card transfers without a transaction link. It does not cause the transfer to fail, and it does not pull the transaction across on its own.

Source: CURR_AMT · Destination: Balance

This is a recommended field. iPaaS.com accepts the card without it, but the balance is what makes the card usable for reporting and redemption tracking, so it should be mapped for any meaningful gift card sync. The current remaining value on the card at the time of transfer. This is a point-in-time figure — it reflects the balance when the transfer ran, not a live value. Subsequent redemptions update it on the next transfer of the card. The Status mapping in this collection reads the same balance to decide whether a card counts as Redeemed.

Source: ORIG_DAT · Destination: PurchaseDate

This is an optional field. The date the card was originally issued in NCR Counterpoint. Used for reporting and for age-based analysis of outstanding balances.

Source: return await GetSpaceportIdAsync(ORIG_CUST_NO, "customer", SpaceportSystemId); · Destination: CustomerId

This is an optional field. Links the card to the customer it was issued to. The formula takes the originating Counterpoint customer number and looks up the matching customer already transferred into iPaaS.com. If that customer has not been transferred yet, or the card was issued without one, the mapping resolves to empty and the card transfers unlinked. It does not transfer the customer as a prerequisite, so subscribers who want cards linked to customers should ensure customers are transferring before enabling this collection.

Source: SpaceportSystemId · Destination: Originating_SystemId

This is a required field — iPaaS.com rejects the card without it, and the value must be greater than zero. Records which connected system the gift card originated in, so that later activity against the card can be attributed back to its source. The value is supplied automatically by iPaaS.com for the subscription running the transfer — subscribers do not configure it and should not replace it with a fixed value, as a hardcoded or zero value causes the transfer to be rejected.

Source: EXP_DAT · Destination: ExpirationDate

This is an optional field. The date the card expires, where NCR Counterpoint holds one. Cards issued without an expiry transfer with this field empty. The Status mapping in this collection reads this date, together with the card's no-expiry flag, to decide whether a card counts as Expired.

Source: ORIG_AMT · Destination: OriginalAmount

This is a recommended field. iPaaS.com accepts the card without it, but omitting it leaves the card's issued value unrecorded, so it should be mapped for any meaningful gift card sync. The value the card was originally issued for, as opposed to Balance, which is what remains. The pair together allow redemption to be reported without needing the activity history. Counterpoint always supplies this value, holds it to two decimal places, and does not permit it to be negative — so a negative original amount indicates the mapping has been changed to a different source rather than a genuine Counterpoint value.

Source: Lookup Translation — **CP Gift Card Status To iPaaS** · Destination: Status

This is a required field — iPaaS.com rejects the card without it. Allowed values: Active, Expired, Void, and Redeemed. Derives the card's state in iPaaS.com. Unlike a typical lookup translation, which matches one source value to one destination value, this table is evaluated in order and the first row whose condition holds decides the result. The final row is a catch-all, so every card receives a status.

Because the rows are evaluated in order, their sequence matters: a fully redeemed card that is also void reports as Void, not Redeemed. Subscribers who need different precedence can reorder the rows, but two constraints apply. The catch-all row must remain last — because Status is required, a card matching none of the rules is rejected rather than transferred without one. And each row's result must remain one of the four allowed values; renaming a row to a custom status causes the transfer to fail.

Parent: Add NCR Counterpoint Gift Card TO iPaaS.com.

Source: Lookup Translation — **CP Gift Card Activity ACTIV_TYP To iPaaS** · Destination: ActivityType

This is a required field — iPaaS.com rejects the activity without it. Allowed values: Issue, Redeem, Void, Reinstate, and Adjust. Describes what happened to the card. NCR Counterpoint records the activity as a single-letter code, and this translation converts it to the wording iPaaS.com uses.

Two Counterpoint codes both resolve to Adjust. The second of the two occurs only on store credits, never on gift cards — Counterpoint permits it on store-credit activity but not on gift-card activity. Once in iPaaS.com an adjustment cannot be traced back to which of the two codes produced it.

This translation covers every activity code Counterpoint permits, across both gift cards and store credits, so no activity should arrive without a match. The set is fixed in Counterpoint and does not grow on its own. Subscribers should still leave the rows in place: because this field is required, an activity whose code found no match would be rejected rather than transferred without a type, and each row's result must remain one of the five allowed values — a custom value causes the transfer to fail.

Source: LST_MAINT_DT · Destination: Timestamp

This is a recommended field. iPaaS.com accepts the activity without it, but activity history is only meaningful in sequence, so it should be mapped. When the activity was recorded. This is Counterpoint's last-maintained date for the activity row rather than a dedicated activity timestamp, so it reflects the last time the row changed. For activity that is written once and never amended these are the same; for rows that are later corrected, the timestamp moves to the correction. Subscribers reconciling activity against till or register times should expect this behavior.

Source: AMT · Destination: Amount

This is a recommended field. iPaaS.com accepts the activity without it, but an activity with no amount records that something happened without recording what, so it should be mapped. The value of the individual activity — what was loaded, redeemed, or adjusted — not the card's balance. The card's remaining balance is carried separately by the Balance mapping on the parent collection, Add NCR Counterpoint Gift Card TO iPaaS.com. Amounts are transferred with the sign Counterpoint records them with, so subscribers should not assume redemptions are always negative without confirming against their own data.

Source: STR_ID · Destination: Location

This is an optional field. The Counterpoint store the activity took place at. This is passed through as the store's identifier as it appears in Counterpoint — it is not matched against the iPaaS.com Location records that the location collections transfer, so the value here will not necessarily correspond to a location subscribers see elsewhere in iPaaS.com.

Source: DOC_NO · Destination: TransactionReferenceId

This is an optional field. The Counterpoint document number the activity occurred on, passed across for reference. It is not present on every activity — balance adjustments made outside a transaction have none — and it does not create a link to a transaction record in iPaaS.com. Subscribers should treat it as a human-readable reference for tracing an activity back to a receipt, not as a relationship they can report against. The card as a whole is linked to its originating transaction by the TransactionId mapping on the parent collection.

Source: GFC_NO · Destination: Number

This is a required field — iPaaS.com rejects the card without it. The gift card number as issued in NCR Counterpoint, stored there as text of up to 30 characters and always populated. This is the value subscribers and their MiSP use to identify the card in both systems, and it is what iPaaS.com stores as the card's own identifier. The card being updated is matched by the Counterpoint gift card id held on its external-ID record, which was written when the card first transferred through Add NCR Counterpoint Gift Card TO iPaaS.com — so this mapping refreshes the number on the matched card rather than being the value used to find it.

Source: DESCR · Destination: Description

This is an optional field. The free-text description recorded against the gift card in NCR Counterpoint. Carried across unchanged for reference and reporting, and refreshed from Counterpoint on every update, so a description edited in Counterpoint replaces whatever iPaaS.com currently holds. Counterpoint stores this as text of up to 30 characters and always supplies a value, so the description always arrives and is never longer than 30 characters. Subscribers replacing this mapping with a formula are not held to that limit by iPaaS.com, but should keep results short enough to stay readable alongside descriptions that came straight from Counterpoint.

Source: (IsStoreCredit ? "Store Credit" : "Gift Card") · Destination: Type

This is a required field — iPaaS.com rejects the card without it. Allowed values: Giftcard and Store Credit. Records whether the record is a gift card or a store credit. NCR Counterpoint keeps these in two separate places, and the integration reads both into this one collection. IsStoreCredit is not a column subscribers will find in their Counterpoint database — the integration sets it while reading the record to indicate which of the two the record came from. When it is set, this mapping produces Store Credit; otherwise it produces Gift Card, which iPaaS.com accepts and normalizes to the Giftcard value. Subscribers replacing this formula should supply one of the two allowed values. This mapping is identical to the one on Add NCR Counterpoint Gift Card TO iPaaS.com, so a card's type is re-evaluated on every update and stays consistent with how it was first transferred.

Source: return await DocumentSpacePortIdFromDocIdAsync(ORIG_DOC_ID); · Destination: TransactionId

This is an optional field that references the iPaaS.com transaction id. Links the gift card back to the transaction it was sold on. The formula takes the originating Counterpoint document and looks up the matching transaction already transferred into iPaaS.com. If that transaction has not been transferred — or the card was not issued against one — the mapping resolves to empty and the card updates without a transaction link. It does not cause the transfer to fail, and it does not pull the transaction across on its own.

Because the lookup runs again on every update, this mapping behaves differently from the other links on this collection: a card that first transferred before its originating transaction existed in iPaaS.com gains the link on a later update, once that transaction has been transferred. Subscribers who find cards unlinked should transfer the transactions and let the cards update again rather than re-adding the cards.

Source: CURR_AMT · Destination: Balance

This is a recommended field. iPaaS.com accepts the card without it, but the balance is what makes the card usable for reporting and redemption tracking, so it should be mapped for any meaningful gift card sync. The current remaining value on the card at the time of transfer. Keeping this value current is the main reason this collection exists: a card's balance changes every time it is redeemed or topped up, and this mapping is what carries those changes into iPaaS.com after the card was first added by Add NCR Counterpoint Gift Card TO iPaaS.com. This remains a point-in-time figure — it reflects the balance when the update ran, not a live value, so a card redeemed after the last update reports its previous balance until the next one. The Status mapping in this collection reads the same balance to decide whether a card counts as Redeemed.

Source: ORIG_DAT · Destination: PurchaseDate

This is an optional field. The date the card was originally issued in NCR Counterpoint. Used for reporting and for age-based analysis of outstanding balances. Counterpoint permits this to be empty, in which case the card updates with this field cleared. Counterpoint records it as a date without a time.

Source: DestinationValue.CustomerId · Destination: CustomerId

This is an optional field. The mapping returns the customer link already stored on the gift card record in iPaaS.com, which leaves that link exactly as it is. It does not read anything from Counterpoint and does not look the customer up — that lookup happens once, when the card is first transferred by Add NCR Counterpoint Gift Card TO iPaaS.com. The purpose here is preservation: without this mapping the update would clear the link that the add established.

Subscribers should understand the limit this creates. A card whose customer had not yet transferred into iPaaS.com when the card was added is linked to nobody, and no later update backfills that link — the card stays unlinked no matter how many times its balance refreshes. Subscribers who want cards linked to customers should ensure customers are transferring before cards are first added. Where cards have already been added unlinked, refreshing them through this collection will not repair them; subscribers in that position should raise it with their MiSP rather than expecting an update to resolve it.

Source: DestinationValue.Originating_SystemId · Destination: Originating_SystemId

This is a required field — iPaaS.com rejects the card without it, and the value must be greater than zero. Records which connected system the gift card originated in, so that activity against the card can be attributed back to its source. The mapping returns the value already stored on the gift card record in iPaaS.com, which preserves the system recorded when the card was first transferred by Add NCR Counterpoint Gift Card TO iPaaS.com. This is deliberate: the system a card originated in is a fact about its history and does not change because the card was updated. Subscribers do not configure this and should not replace it with a fixed value, as a hardcoded or zero value causes the transfer to be rejected.

Source: EXP_DAT · Destination: ExpirationDate

This is an optional field. The date the card expires, where NCR Counterpoint holds one. Cards issued without an expiry update with this field empty. Refreshed from Counterpoint on every update, so an expiry extended or removed in Counterpoint is carried into iPaaS.com. The Status mapping in this collection reads this date, together with the card's no-expiry flag, to decide whether a card counts as Expired.

Source: DestinationValue.OriginalAmount · Destination: OriginalAmount

This is a recommended field. The mapping returns the value already stored on the gift card record in iPaaS.com, which preserves the issued value recorded when the card was first transferred by Add NCR Counterpoint Gift Card TO iPaaS.com. The value the card was originally issued for, as opposed to Balance, which is what remains. The pair together allow redemption to be reported without needing the activity history.

This mapping differs from its counterpart on the add collection, which reads the issued amount from Counterpoint directly. Preserving it here is deliberate — the amount a card was issued for does not change when its balance does. Subscribers should note the consequence: if a card's original amount is corrected in Counterpoint after the card has been added, that correction does not reach iPaaS.com through this collection. Subscribers who need such corrections reflected should validate the behavior in a staging environment before relying on it in production.

Source: Lookup Translation — **CP Gift Card Status To iPaaS** · Destination: Status

This is a required field — iPaaS.com rejects the card without it. Allowed values: Active, Expired, Void, and Redeemed. Derives the card's state in iPaaS.com. Unlike a typical lookup translation, which matches one source value to one destination value, this table is evaluated in order and the first row whose condition holds decides the result. The final row is a catch-all, so every card receives a status.

Because the rows are evaluated in order, their sequence matters: a fully redeemed card that is also void reports as Void, not Redeemed. Subscribers who need different precedence can reorder the rows, but two constraints apply. The catch-all row must remain last — because Status is required, a card matching none of the rules is rejected rather than transferred without one. And each row's result must remain one of the four allowed values; renaming a row to a custom status causes the transfer to fail.

This is the same translation the add collection uses, so a card's status is derived the same way whether it is being added or updated. Two of the rules are time-sensitive and are re-evaluated on every update, which matters for this collection in particular: a card becomes Redeemed once updates bring its balance to zero, and a card becomes Expired once its expiry date has passed. Neither transition happens on its own — a card that expired in Counterpoint yesterday continues to report Active in iPaaS.com until this collection next updates it.

Source: DestinationValue.ReceivingCustomer · Destination: ReceivingCustomer

This is an optional field. The name of the person a gift card was bought for, as opposed to the customer who bought it. NCR Counterpoint has no equivalent of this field, so there is nothing in Counterpoint for it to be read from. The mapping returns the value already stored on the gift card record in iPaaS.com, which leaves it exactly as it is.

This mapping exists to protect the value rather than to supply it. Because Counterpoint cannot provide a recipient, an update that did not preserve this field would clear whatever iPaaS.com holds every time a card's balance refreshed. Subscribers whose recipient details are captured elsewhere in iPaaS.com — by a webstore or another integration — can rely on those details surviving Counterpoint updates. Subscribers should not expect this collection to populate the field.

Source: DestinationValue.ReceivingCustomerEmail · Destination: ReceivingCustomerEmail

This is an optional field. The email address of the person a gift card was bought for, and the counterpart to ReceivingCustomer. NCR Counterpoint has no equivalent of this field, so there is nothing in Counterpoint for it to be read from. The mapping returns the value already stored on the gift card record in iPaaS.com, which leaves it exactly as it is, and exists for the same reason as ReceivingCustomer — to keep a recipient email captured elsewhere in iPaaS.com from being cleared each time a card's balance refreshes from Counterpoint. Subscribers should not expect this collection to populate the field.

Parent: Update NCR Counterpoint Gift Card TO iPaaS.com.

Source: Lookup Translation — **CP Gift Card Activity ACTIV_TYP To iPaaS** · Destination: ActivityType

This is a required field — iPaaS.com rejects the activity without it. Allowed values: Issue, Redeem, Void, Reinstate, and Adjust. Describes what happened to the card. NCR Counterpoint records the activity as a single-letter code, and this translation converts it to the wording iPaaS.com uses.

Two Counterpoint codes both resolve to Adjust. The second of the two occurs only on store credits, never on gift cards — Counterpoint permits it on store-credit activity but not on gift-card activity. Once in iPaaS.com an adjustment cannot be traced back to which of the two codes produced it.

This translation covers every activity code Counterpoint permits, across both gift cards and store credits, so no activity should arrive without a match. The set is fixed in Counterpoint and does not grow on its own. Subscribers should still leave the rows in place: because this field is required, an activity whose code found no match would be rejected rather than transferred without a type, and each row's result must remain one of the five allowed values — a custom value causes the transfer to fail.

This is the same translation used by Add/Update NCR Counterpoint Gift Card Activity TO iPaaS.com, so an activity's type is derived the same way whichever collection carries it. Subscribers editing the rows should be aware the change affects both.

Source: LST_MAINT_DT · Destination: Timestamp

This is a recommended field. iPaaS.com accepts the activity without it, but activity history is only meaningful in sequence, so it should be mapped. When the activity was recorded. This is Counterpoint's last-maintained date for the activity row rather than a dedicated activity timestamp, so it reflects the last time the row changed. For activity that is written once and never amended these are the same; for rows that are later corrected, the timestamp moves to the correction. Subscribers reconciling activity against till or register times should expect this behavior.

Source: AMT · Destination: Amount

This is a recommended field. iPaaS.com accepts the activity without it, but an activity with no amount records that something happened without recording what, so it should be mapped. The value of the individual activity — what was loaded, redeemed, or adjusted — not the card's balance. The card's remaining balance is carried separately by the Balance mapping on the parent collection, Update NCR Counterpoint Gift Card TO iPaaS.com. Amounts are transferred with the sign Counterpoint records them with, so subscribers should not assume redemptions are always negative without confirming against their own data.

Source: STR_ID · Destination: Location

This is an optional field. The Counterpoint store the activity took place at. This is passed through as the store's identifier as it appears in Counterpoint — it is not matched against the iPaaS.com Location records that the location collections transfer, so the value here will not necessarily correspond to a location subscribers see elsewhere in iPaaS.com.

Source: DOC_NO · Destination: TransactionReferenceId

This is an optional field. The Counterpoint document number the activity occurred on, passed across for reference. It is not present on every activity — balance adjustments made outside a transaction have none — and it does not create a link to a transaction record in iPaaS.com. Subscribers should treat it as a human-readable reference for tracing an activity back to a receipt, not as a relationship they can report against. The card as a whole is linked to its originating transaction by the TransactionId mapping on the parent collection.

Errors raised while transferring these records surface at Dashboard / Integration Monitoring / Error Logs. The specific messages, their causes and their resolutions are documented in NCR Counterpoint Error Messages. A record stopped by an error is not retried automatically; it must be resolved manually.