SPIn Specification

## Sections
• [Secure Payment Interface (SPIn)](https://app.theneo.io/dejavoo/spin-specification/secure-payment-interface-spin.md): SPIn is a robust semi-integration solution that bridges Point of Sale (POS) systems—such as cash registers, billing software, or tills—with Dejavoo Payment Terminals. By creating a secure, cloud-based connection, SPIn enables the Merchant’s Host System to communicate seamlessly with Dejavoo terminals. This integration allows the Host System to send payment requests to the terminal and receive transaction data back upon completion. The SPIn solution enhances operational efficiency by simplifying payment reconciliation and reducing the risk of human errors. Importantly, sensitive cardholder data (e.g., PAN, expiration dates) never touches the Host System, which eliminates PCI compliance for merchants. Use Cases Third-party POS providers aiming to offer merchants a payment solution free from PCI compliance concerns. Merchants seeking a seamless, unified point-of-sale experience that integrates payment acceptance with record-keeping systems. Integration Options REST API : For integration using RESTful methods, refer to the SPIn REST API Documentation . SOAP API : For XML-based requests and responses, continue exploring this document. SPIn is designed to streamline payments, minimize complexity, and provide merchants with a secure and hassle-free transaction process. All of our payment applications included in this page comply with PCI DSS (Payment Card Industry Data Security Standard). PCI DSS is a set of security standards designed to ensure that any company accepting, processing, storing, or transmitting credit card information maintains a secure environment. By adhering to these guidelines, we ensure that all payment data is handled with the highest level of security, protecting sensitive information and preventing data breaches.
• [SPIn specification API](https://app.theneo.io/dejavoo/spin-specification/spin-specification-api.md): Version History Title Description Title Date Version Details 10/01/22 1.0 Initial release 10/10/22 1.1 Added support for Tags 11/01/22 1.2 Added support for iPOSToken 20/02/23 1.3 Added PerformedBy Tag 5/04/23 1.4 Added userChoice option to PaymentType 21/07/23 1.5 Added support for user input and summary reports to fetch batch details from the payment device. 06/02/24 1.7 Added support for level data, dual pricing requests, and the ISVID indicator. 10/09/24 1.8 Enabled cart Items display API 12/12/24 1.9 Added fee support tag in sale request 09/06/24 1.10 Added Multi MerchantId 07/07/25 2.0 Added Get Card API support 25/07/25 2.1 Added dynamic capabilities for display cart items API 03/10/25 2.2 Updated data tags for Level 3 and new VISA CEDP line item acceptance 18/11/25 2.3 Added new ReconId tag for Fiserv reconciliation support 05/03/26 2.4 EBT Balance API support 08/04/26 2.5 Added Reduced State Tax, State Tax and City Tax 24/04/26 2.6 Added support for AutoRental Prerequisites iPOSpays-powered Dejavoo terminal Login credential to iPOSpays For Sandbox (UAT) Users should be onboarded on iPOSpays sandbox(UAT) environment as a merchant and have a valid TPN. For Production (Live) Users should be onboarded on iPOSpays production environment as a merchant and have a valid TPN. If you do not have a TPN, contact your ISO or devsupport@dejavoo.io Steps to Setup Step 1 : Login to iPOSpays Step 2 : Enable SPIn for your TPN. Go to S.T.E.A.M -> Edit Parameters -> search and select your TPN Click Edit Parameter Click Integrations Under Type of Integrations , select SPIn and choose Cloud under Spin Mode . Copy the Register ID and Auth Key. You will need these values when calling the API from the Host System. Watch This Video for a Visual Walkthrough of the Steps SPIn Proxy (Troubleshooting) SPIn proxy helps integrators ensure the connection is established between SPIn and the payment terminal. Login to iPOSpays Click “Troubleshooting SPIn Proxy” Enter your TPN Click “Check POS Connection” If the arrow between the SPIn logo and the payment terminal logo is lit up in green, it indicates that the connection has been successfully established. If the arrow is lit up in red, it means the connection has not been established and there is an issue. In this case, please reach out to us at support@dejavoosystems.com . We also offer simulated testing to verify if the generated Auth Key and TPN are working and ready to be configured with the Host System. TPN & Auth Key Check – Short Steps: TPN Check: Click “Check Register Connection” and select “Show TPN.” Confirm pop-up on the terminal. Verify the connection: If the arrow light is green , the TPN will appear on the portal, indicating a successful connection. If the arrow light is red , the connection has failed. For failed connections, contact support at support@dejavoosystems.com . Auth Key Check: Click “Check Register Connection” and select “Show Auth Key.” Confirm pop-up on the terminal. Verify the connection: If the arrow light is green , the Auth Key will appear on the portal, indicating a successful connection. If the arrow light is red , the connection has failed. For failed connections, contact support at support@dejavoosystems.com . Sample Source Code Spin Specification
• [Transaction Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/transaction-request.md): The current chapter defines the XML format of the request to run a transaction via HTTP GET method. After sending transaction request to payment terminal, please wait for a timeout period (default timeout is 120 seconds). Within the timeout period SPIn proxy will respond either with approval or decline or time out. If the transaction timeout, please use the Transaction Status Request to check the status. Example - HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
  • [Payment Type as user Choice](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/transaction-request/payment-type-as-user-choice.md): Example - HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Set Custom Timeout for Transactions](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/set-custom-timeout-for-transactions.md): The default timeout after which SPIn Proxy will send the “operations timed out” error is 120 seconds. However, some scenarios may require a longer timeout. For instance, during curbside checkout, where the merchant takes the payment device to the customer’s car, the register, POS, or server may need more time to complete the transaction. To set a custom timeout, use the OperationalTimeout tag to adjust the timeout period accordingly, ensuring the process is not prematurely interrupted. Plain text <OperationalTimeout>120</OperationalTimeout> <OperationalTimeout>120</OperationalTimeout> Example - HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Capture/Ticket Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/capture-ticket-request.md): Pre-Auth (Auth-Only) transactions allow users to hold a specific amount for processing at a later time without needing to re-enter account details. A Capture/Ticket Request is used to finalize an Auth-Only (Ticket) transaction, ensuring the held amount is processed without requiring the account data to be entered again. Follow the steps and references outlined in this section to perform a Capture/Ticket transaction. Capture request used to post capture an Auth only transaction without re-entering account data. Example - HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Tip Adjustment Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/tip-adjustment-request.md): Tip Adjustment enables users to modify the tip amount on a transaction before the batch is settled and sent to the processor. This feature is available only if tip is enabled for the TPN on the portal. Additionally, the host system must use data from the original transaction to allow the terminal to locate and update the tip amount. Follow the steps and references outlined in this section to perform a tip adjustment. Example - HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Void Transaction Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/void-transaction-request.md): A Void Transaction request is used to cancel a previously authorized transaction before the batch is closed and sent to the processor. The host system must use data from the original transaction to allow the terminal to locate and process the Void request. Follow the steps and references outlined in this section to void a transaction. Example - HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Transaction Status Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/transaction-status-request.md): A Transaction Status Request allows the host system to check the result of a previously initiated transaction, typically when communication between the host system and the terminal was interrupted while the transaction request was pending. Follow the steps and references outlined in this section to check the transaction status. Example: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Request For Settlement](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/request-for-settlement.md): A Request for Settlement is used to initiate the terminal’s batch settlement with the payment processor. At the end of the business hours, when a merchant is ready to close, all transactions processed during their operating hours must be submitted to the processor to ensure the funds are transferred to their bank account. Follow the steps and references outlined in this section to initiate the terminal’s batch settlement. Example: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Printout Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/printout-request.md): If the selected terminal model includes an integrated printer, it can be used as an external printer for the integrated POS system’s printing functionality. The terminal supports printing in the Courier New font, with a default width of 24 characters per line. Follow the steps and references outlined in this section to print transaction receipts by sending a request from the server, register, or POS to the integrated Dejavoo payment terminal. Example : HTTPS://test.SPInpos.net:443/SPIn/cgi.html?Printer= If two text strings are sent sequentially until <lf> is found, these first line will be printed left justified and second – right justified on the same line.
• [User Choice Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/user-choice-request.md): This API is used to prompt the cardholder to select their preferred payment type, which is displayed on the payment terminal. The selected option is then passed back to the register. For example, the register can initiate a transaction and send a request to the payment terminal. If one of the options presented is a debit card and the cardholder chooses to pay using it, the chosen payment type (Debit card)will be included in the response sent back to the register. Follow the steps and references outlined in this section to prompt a user choice request on the payment terminal. Example : HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [User Input Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/user-input-request.md): With the User Input request API, customers will be prompted to enter the required additional data on the terminal. Use cases In a restaurant setting, the POS application can prompt the waiter’s payment device to request an order number. The waiter enters the order number directly on the terminal, which is sent back to the POS application. This enables the payment amount to be processed for the specified order, reducing the need for the waiter to make multiple trips between the cash counter and the table. Follow the steps and references outlined in this section to prompt a user input request on the payment terminal. Sample Request and Response: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction= Type: NUMERIC
  • [TYPE : ALPHANUMERIC](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/user-input-request/type-alphanumeric.md)
  • [TYPE : ALPHA](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/user-input-request/type-alpha.md)
  • [TYPE : MONEY](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/user-input-request/type-money.md)
  • [TYPE : INFO](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/user-input-request/type-info.md)
• [Get Card Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/get-card-request.md): The GetCard request API allows the POS system to prompt the customer to present their card using a supported method—such as swiping or manually entering the card number—on the terminal. Once the card is provided, the relevant card data is securely transmitted back to the POS for further use. Use Case This API is ideal for merchants who support features like gift cards, loyalty programs, or customer registration. For example, when a customer wants to redeem points, link their account, or activate a gift card, the merchant can trigger this request to let the customer enter their card details directly on the terminal—avoiding manual entry on the POS and ensuring a secure and smooth experience. Follow the steps and field references below to prompt a GetCard request on the payment terminal. Example: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Batch Report Request](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/batch-report-request.md): The broadcast batch report service allows users to retrieve the status and details of the current open batch, which includes all transactions processed during the user’s business hours. The ReportType request field specifies the type of report to be generated. The Summary Report provides an overview of the batch, including totals for each transaction type. The Daily Report offers a detailed breakdown of every transaction conducted on each day. Follow the steps and references outlined in this section to retrieve the status and details of a current open batch. Example: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Auto Rental Data](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/auto-rental-data.md): ISVs/merchants using Auto Rental software can send the required Auto Rental transaction indicators and data elements — such as rental agreement details, rental dates, and related transaction information—through SPIn to Dejavoo terminals. Providing this data allows the transaction to be properly identified as an Auto Rental transaction and helps qualify for optimized interchange rates Sample Request and Response: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Level 2 & Level 3 Data](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/level-2-and-level-3-data.md): Merchants using the Secure Payment Interface (SPIn) can transmit L2/L3 data directly from their POS application to the integrated Dejavoo payment terminal. This integration ensures that all necessary transaction details are captured and sent to the processor, facilitating the qualification for reduced interchange rates. To qualify for reduced interchange rates on eligible commercial, corporate, fleet, and purchase card transactions, it is essential to provide detailed transaction information. This information includes both order-level and item-level data, as outlined in the Commercial Enhanced Data Program (CEDP). CEDP has replaced the previous Level 2 and Level 3 programs and introduces more stringent data requirements and validation processes. Follow the steps and references outlined in this section to transmit Level 2 and Level 3 transaction data from the cash register application to the integrated Dejavoo payment terminal. Example: HTTPS://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Send Card Price for L2/L3](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/send-card-price-for-l2-l3.md): In case the host calculates the card price, follow the steps and references outlined in this section to transmit the card and cash prices, along with other Level 2 and Level 3 transaction data, from the cash register application to the integrated Dejavoo payment terminal. Example: https://test.SPInpos.net:443/SPIn/cgi.html?TerminalTransaction=
• [Display Cart Items on Terminal](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/display-cart-items-on-terminal.md): The Display Cart Items feature allows you to show line items on the terminal screen, enabling customers to review their cart during checkout. This can be used flexibly depending on your integration flow. Terminal Listening Behavior When you send only line item requests , the terminal remains in listening mode . This allows you to continue sending updates as items are added to the cart. However, once a payment request is sent—either on its own or as part of a combined request—the terminal exits listening mode and cannot accept further requests until it returns to the listening screen. Customer Alert with notifyCustomer To enhance the customer’s checkout experience, the notifyCustomer tag can be used to trigger an audible tone on the payment terminal whenever a cart update is received. This is particularly useful in fast-paced retail environments where items are scanned rapidly or when the customer’s attention needs to be directed toward the screen. By setting this optional Boolean field to true , the terminal emits a subtle notification sound every time a new cart item is displayed. If set to false or omitted , the terminal will update silently without auditory cues. Use Case 1: Real-Time Cart Updates This flow is suitable for environments where items are added one by one, such as scanning at a supermarket checkout. The terminal updates in real time to display the cart contents as they’re sent. The key point here is that the terminal only shows what is included in each request—it doesn’t maintain a history of previous items. This gives you full control over how the cart appears on the terminal. There are two main ways to use this: Full Cart View Send the full list of items in each request, so the terminal displays an incrementally growing cart. Example: Send: Item A → terminal shows: A Send: A, B → terminal shows: A, B Send: A, B, C → terminal shows: A, B, C S Single Item View Send only the new item each time. The terminal will show just that item, replacing the previous one. Example: Send: Item A → terminal shows: A Send: Item B → terminal shows: B Send: Item C → terminal shows: C Whether the terminal displays a running list of all items or just the most recent one depends entirely on how you format the line item request. The terminal simply displays what it receives. Once the cart is ready, send a payment request . The terminal automatically transitions to the payment screen, and if tipping is enabled for the TPN, the tip screen will appear before proceeding. Tip screen appears first because tipping was enabled for the TPN At this point, the terminal is no longer listening and cannot accept any additional requests. Sample Request: Displaying Cart Items Only This XML request is used when you want to show cart items on the terminal screen without initiating payment . The terminal remains in listening mode , allowing additional line items to be sent and displayed in real time. XML <request> <AuthKey>f9eGebRfss</AuthKey> <TPN>z11devtest03</TPN> <PosID>2122</PosID> <notifyCustomer>true</notifyCustomer> <!-- Plays a tone on the terminal when the cart is updated to alert the customer --> <Cart> <Amounts> <Amount> <Name>Discounts</Name> <Value>1141</Value> </Amount> <Amount> <Name>Subtotal</Name> <Value>2154</Value> </Amount> <Amount> <Name>Taxes</Name> <Value>599</Value> </Amount> <Amount> <Name>Total</Name> <Value>2753</Value> <Total/> </Amount> </Amounts> <Items> <Item> <Name>Lunch 4</Name> <Price>807</Price> <UnitPrice></UnitPrice> <Quantity>1</Quantity> <CustomInfos> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> </CustomInfos> <AdditionalInfo></AdditionalInfo> <Modifiers> <Modifier> <Name>Modifier 3</Name> <Options> <Option> <Name>Value 2</Name> <Price>233</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Business Lunch</Name> <Price>-208</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>AutoDisc10</Name> <Price>-104</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> </Modifiers> </Item> <Item> <Name>Borsch</Name> <Price>723</Price> <UnitPrice></UnitPrice> <Quantity>1</Quantity> <CustomInfos> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> </CustomInfos> <AdditionalInfo></AdditionalInfo> <Modifiers> <Modifier> <Name>Mix</Name> <Options> <Option> <Name>Third</Name> <Price>350</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name>Mikhail Test</Name> <Options></Options> </Modifier> <Modifier> <Name>Fat</Name> <Options> <Option> <Name>Low fat</Name> <Price>1167</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Glass</Name> <Price>15</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Business Lunch</Name> <Price>-403</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>AutoDisc10</Name> <Price>-202</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Changed</Name> <Price>-224</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> </Modifiers> </Item> </Items> </Cart> </request> <request> <AuthKey>f9eGebRfss</AuthKey> <TPN>z11devtest03</TPN> <PosID>2122</PosID> <notifyCustomer>true</notifyCustomer> <!-- Plays a tone on the terminal when the cart is updated to alert the customer --> <Cart> <Amounts> <Amount> <Name>Discounts</Name> <Value>1141</Value> </Amount> <Amount> <Name>Subtotal</Name> <Value>2154</Value> </Amount> <Amount> <Name>Taxes</Name> <Value>599</Value> </Amount> <Amount> <Name>Total</Name> <Value>2753</Value> <Total/> </Amount> </Amounts> <Items> <Item> <Name>Lunch 4</Name> <Price>807</Price> <UnitPrice></UnitPrice> <Quantity>1</Quantity> <CustomInfos> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> </CustomInfos> <AdditionalInfo></AdditionalInfo> <Modifiers> <Modifier> <Name>Modifier 3</Name> <Options> <Option> <Name>Value 2</Name> <Price>233</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Business Lunch</Name> <Price>-208</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>AutoDisc10</Name> <Price>-104</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> </Modifiers> </Item> <Item> <Name>Borsch</Name> <Price>723</Price> <UnitPrice></UnitPrice> <Quantity>1</Quantity> <CustomInfos> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> <CustomInfo> <Name>Total</Name> <Value>2753</Value> </CustomInfo> </CustomInfos> <AdditionalInfo></AdditionalInfo> <Modifiers> <Modifier> <Name>Mix</Name> <Options> <Option> <Name>Third</Name> <Price>350</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name>Mikhail Test</Name> <Options></Options> </Modifier> <Modifier> <Name>Fat</Name> <Options> <Option> <Name>Low fat</Name> <Price>1167</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Glass</Name> <Price>15</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Business Lunch</Name> <Price>-403</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>AutoDisc10</Name> <Price>-202</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> <Modifier> <Name></Name> <Options> <Option> <Name>Changed</Name> <Price>-224</Price> <Quantity>1</Quantity> </Option> </Options> </Modifier> </Modifiers> </Item> </Items> </Cart> </request> Use Case 2: Display Cart with Immediate Payment In this flow, the POS sends a single request that includes both the full list of cart items and the payment request. The terminal displays the cart, along with a CHECKOUT button. When the customer taps CHECKOUT , the terminal proceeds to payment. While this may seem efficient, there’s a trade-off: it relies on the customer to press the CHECKOUT button on the terminal each time. This extra step can slow down the checkout process or lead to confusion—especially in fast-paced or unattended environments. For smoother operation, especially in retail settings with high throughput or minimal staff interaction, it’s often better to keep the checkout action under the POS’s control by using real-time cart updates followed by a separate payment request.
• [ISV ID Indicator](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/isv-id-indicator.md): Independent Software Vendors (ISVs) can include their unique ISV ID in SPIn requests sent to the integrated Dejavoo terminal. This identifier helps track transactions, generate detailed reports, and facilitate the rollout of new features tailored to specific ISVs. By using the ISV ID, merchants and ISVs can gain insights into transaction data while ensuring seamless integration with Dejavoo terminals. This tag is optional. When included in the transaction request, it is passed through FEED integration, allowing the ISV’s POS application and backend systems to identify which ISV initiated the transaction and associate all relevant details accordingly. Follow the steps and references outlined in this section to learn how to include the ISV ID in the SPIn requests sent from your POS application. Example : 100001 - CP-PINPAD which indicates cloud pos pinpad transaction.
• [HSA/FSA Card Acceptance](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/hsa-fsa-card-acceptance.md): Health Savings Account (HSA) and Flexible Spending Account (FSA) cards are commonly used to pay for qualified medical, health, and wellness-related expenses. With this capability, healthcare providers (e.g., clinics, dental offices, pharmacies) can process payments for eligible services and products directly using HSA/FSA cards. Follow the steps and references outlined in this section to accept and transmit HSA/FSA card data from the integrated Dejavoo payment terminal to the payment processor. Example: HTTPS://spinpos.net:443/spin/cgi.html?TerminalTransaction= Dental Clinic Request
• [Get Customer Signatures](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/get-customer-signatures.md): Merchants can use Dejavoo terminals to collect customer signatures for various purposes, including agreements, prescriptions, treatment plans, or even after completing transactions. These documents are sent directly from the POS system to the terminal for the customer's review and signature. Follow the steps and references outlined in this section to configure the requests required by the cash register application to facilitate the collection of customer signatures. Sample Request and Response: HTTPS://test.spinpos.net:443/spin/cgi.html?TerminalTransaction=
• [Multi MID](https://app.theneo.io/dejavoo/spin-specification/server-register-pos-to-terminal-request-format/multi-mid.md): Multi Merchant IDs (MMID) allows businesses operating under a single payment terminal to route transactions to different Merchant IDs (MIDs), each associated with a specific business entity, department, or service category. This is especially useful for environments like salons, medical offices, or multi-brand retail locations where different revenue streams must be tracked and settled separately. In the iPOSpays environment, each MID is tied to a specific TPN (Terminal Provider Number). When MMID is enabled: The TPN tag must contain the Master TPN, which represents the primary terminal setup. The MerchantId tag must contain the transacting TPN, which determines the MID under which the transaction should be processed. Sample MerchantId tag XML <MerchantId>123456789143</MerchantId> <MerchantId>123456789143</MerchantId>
• [Error Sample](https://app.theneo.io/dejavoo/spin-specification/error-sample.md): Type of Errors: <ResultCode>2</ResultCode> — Error from SPIn Proxy <ResultCode>1</ResultCode> — Error from Terminal