POSLavu

We are integrated with two swipe devices.
> - MagTek iDynamo
> - Blue Bamboo P25-MFi 

 The MagTek iDynamo is the preferred device as you are able to charge the iPad while it is plugged in via a mico USB port on the back. It connects directly to the iPad via the 30 pin port. Additionally, the MagTek iDynamo is a more affordable option.

   For the MagTek iDynamo: The iDynamo must be injected with the Gateway and the Merchant Key information by MagTek, contacted by an MSP.

   Gateway:If you already have a credit card provider (aka CC processor) and only require Gateway services, TGate may be able to work with your provide and        supply you with the MagTek iDynamo swipe device. To inquire about your existing processors compatibility with TGate as the gateway, contact TGate.

TGate :Steve Brown  steven@zephyrhardware.com 240-489-2926

If you don't have a credit card processor (aka CC provider or platform), the following is a list MSP's integrated on the MagTek iDynamo for POSLavu.

> Mercury Payment Systems

Chris Bjork:Business Development  Phn: 970-335-4852 Fax: 970-335-4732 www.mercurypay.com

For the Blue Bamboo P25-M swipe device:
 POSLavu is integrated with Authorize.net and RedFin for the Blue Bamboo P25-M.

> You want to have your MSP contact us to discuss integration. You will need to get the MFi version to be configured for use with Apple IOS. The Blue Bamboo P25-M also features a small receipt printer however POSLavu is not configured with this feature at this time. This means that card swiping is the only function available on the BlueBamboo, printing via it's small receipt printer is not available at this time.

MPORTANT NOTE FOR ALL GATEWAYS: Credit card batches run from Batch Settlement to Batch Settlement and do not necessarily correspond to the date or the day start/end time. A merchant setup for manual batch settlement may keep a batch open for several days, though it is recommended that the batch be settled at least once a day. In case a merchant does keep a batch open for more than one day and wants to be able to submit tips, all tips for all days must be submitted before the batch is settled in order for the tips to be processed.
>
> For instance, if a batch is left open from August 12th to August 15th, pressing the "Settle Credit Card Batch" while on the End of Day screen for the 12th after submitting the tips for the 12th will settle all the transactions that occurred from the 12th to the 15th, not just the transactions from the 12th. All the transactions from the 12th to the 15th belong to the same batch. The tip adjustments must first be submitted for the 12th, 13th, 14th, and 15th before settling the batch in order for the tips to be processed.
>
>
> ---- Authorize.net ----
>
> Integration data 1: API LOGIN
> Integration data 2: TRANSACTION KEY
> Integration data 3: leave blank
> Integration data 4: leave blank
>
> Compatible Card Readers: BlueBamboo MFi P25-M, LineaPro
>
> The default transaction type can either be set to Sale or Auth, whether or not the merchant wants to be able to perform tip adjustments. It is recommended that it be set to Sale.
>
> Authorize.net does not support Tip Adjustments and will not allow an Authorization to be captured for an amount greater than the amount for which is was originally authorized. For this reason, Tip Adjustments are processed as separate Sale (AUTH_CAPTURE) transactions when the back end user clicks on "Settle Credit Card Batch", regardless of the default transaction type being used. Tip transactions should be expected to appear as separate transactions on customers' bank or card statements.
>
> Any card tip editing prior to a batch settlement does not involve the gateway.
>
> Returns (CREDITs) can only issued for transactions that have been captured.
>
> There is no defined credit card batch held in the Authorize.net system beyond what may be considered a batch in the POSLavu system. This "batch" consists of any uncaptured Auth (AUTH_ONLY) transactions and any potential Sale (AUTH_CAPTURE) transactions performed for tips.
>
>
>
> ---- MerchantWARE ----
>
> Integration data 1: SITE ID
> Integration data 2: KEY
> Integration data 3: COMPANY NAME
> Integration data 4: leave blank
>
> Compatible Card Readers: BlueBamboo MFi P25-M, iDynamo, LineaPro
>
> Supports Tip Adjustments (ApplyTips) for Sale transactions and PreAuthCaptures (IssuePostAuths) for Auth transactions. The value to use for the default transaction type may depend upon the processor, merchant service provider, or bank being used by the merchant. MerchantWARE should advise.
>
> Credit card batch is held by MerchantWARE's system. The merchant has the option of having the batch automatically settle at a certain time each day or to be manually settled by the merchant at the merchant's discretion. Some processors may not support manual batch settlement.
>
> The batch is manually settled when the back end user presses "Settle Credit Card Batch", at which point a CaptureAll (IssueBatch) is sent to MerchantWARE.
>
>
>
> ---- Mercury ----
>
> Integration data 1: MERCHANT ID
> Integration data 2: PASSWORD
> Integration data 3: HOSTED CHECKOUT MERCHANT ID
> Integration data 4: HOSTED CHECKOUT PASSWORD
>
> Compatible Card Readers: iDynamo
>
> The primary merchant account cannot be used to process both keyed-in transactions and End-To-End Encryption (using iDynamo swipes). Keyed-in transactions must then be processed through Mercury's Hosted Checkout system, which requires a separate set of credentials.
>
> Supports Tip Adjustments (Adjusts) for Sale transactions and PreAuthCaptures for Auth (PreAuth) transactions. The value to use for the default transaction type when a merchant wants to be able to perform tip adjustments may depend upon the processor, merchant service provider, or bank being used by the merchant. Mercury should advise.
>
> Credit card batch is held by Mercury's system. The merchant has the option of having the batch automatically settle at a certain time each day or to be manually settled by the merchant at the merchant's discretion. Some processors may not support manual batch settlement.
>
> The batch is manually settled when the back end user presses "Settle Credit Card Batch", at which point a CaptureAll (BatchSummary & BatchClose) is sent to Mercury.
>
> The Hosted Checkout batch is separate from the primary batch but runs parallel to it, so any manual batch settlement requests will be sent for both when the end user presses "Settle Credit Card Batch". In case the merchant opts for auto batch settlement, the time of settlement should be the same for both batches.
>
> Supports Gift Card integration with POSLavu 2.0+
>
>
>
> ---- RedFin ----
>
> Integration data 1: USERNAME
> Integration data 2: KEY
> Integration data 3: leave blank
> Integration data 4: leave blank
>
> Compatible Card Readers: BlueBamboo MFi P25-M, LineaPro
>
> Supports Tip Adjustments (Adjustments) for Sale transactions and PreAuthCaptures (Force Auths) for Auth transactions. The value to use for the default transaction type when a merchant wants to be able to perform tip adjustments may depend upon the processor, merchant service provider, or bank being used by the merchant. RedFin should advise.
>
> Credit card batch is held by RedFin's system. The merchant has the option of having the batch automatically settle at a certain time each day or to be manually settled by the merchant at the merchant's discretion. Some processors may not support manual batch settlement.
>
> The batch is manually settled when the back end user presses "Settle Credit Card Batch", at which point a CaptureAll is sent to RedFin.
>
>
>
>
> ---- TGate ----
>
> Integration data 1: SITE ID
> Integration data 2: KEY
> Integration data 3: leave blank
> Integration data 4: leave blank
>
> Compatible Card Readers: BlueBamboo MFi P25-M, iDynamo, LineaPro
>
> Supports Tip Adjustments (Adjustments) for Sale transactions and PreAuthCaptures (Force Auths) for Auth transactions. The value to use for the default transaction type when a merchant wants to be able to perform tip adjustments may depend upon the processor, merchant service provider, or bank being used by the merchant. TGate should advise.
>
> Credit card batch is held by TGate's system. The merchant has the option of having the batch automatically settle at a certain time each day or to be manually settled by the merchant at the merchant's discretion. Some processors may not support manual batch settlement.
>
> The batch is manually settled when the back end user presses "Settle Credit Card Batch", at which point a CaptureAll is sent to TGate.
>
> Supports Gift and Loyalty Card integration with POSLavu version 2.0+
>
> - - - - - - - - - - - - - - - - - - - -
>
> NOTE: For current POSLavu users - IMPORTANT NOTE FOR ALL GATEWAYS information listed above is available in the POSLavu Backend.
> Settings > Advanced Location Settings > see the Credit Card Integration section > click on the "?" symbol.
>
> Any further inquires please don't hesitate to contact us.
>
> Thank you!
> POSLavu Support