Skip to content

Aurus Integration Overview

Enabling Aurus API in Commerce Server

  • Replace all occurrences of the following adyen api imports with the Aurus equivalents in POS Build
    • api "org.jumpmind.jmc.services:pay-adyen30:$commerceVersion" to api "org.jumpmind.jmc.services:pay-aurus:$commerceVersion"
    • api "org.jumpmind.jmc.point-of-sale:pay-flow-adyen:$commerceVersion" to api "org.jumpmind.jmc.point-of-sale:pay-flow-aurus:$commerceVersion"
  • Specify the spring profiles needed for your configuration
  • aurus and aurus-mpos for proxy with mobile POS (alternatively, run Commerce Base Aurus MPos (H2) configuration)
  • aurus and aurus-cx for proxy with mobile CXConnect (alternatively, run Commerce Base Aurus CX (H2) configuration)
  • aurus and aurus-fixed for TCP (alternatively, run Commerce Base Aurus Fixed (H2) configuration)

Existing software integrations

  • AESDK
    • iOS
    • Android
    • Windows .NET
  • iOS, Android and .NET use the same JMC codebase. One API supports the available implementations, and can be configured per device.
  • Planned upgrades
    • Downloading of AESDK logs from iOS, looking to be in the 24.3 release

Existing hardware integrations

  • Verifone E285
    • Via iOS proxy client
    • We support AESDK mobile calls from commerce server running in the cloud via proxy
  • Ingenico Lane/3600
    • Via installed Windows service

Currently unsupported endpoints

  • /rest/pay/displayScreen
    • Currently unimplemented for Aurus as no clients using Aurus have required customer prompts to be displayed on their payment devices. This could be used for displaying generic prompts to the customer (confirm email, accept terms & conditions, etc.).
  • /rest/pay/getSignature
    • Used for manually capturing a signature for a card authorization. Currently unimplemented for all payment providers, as most pinpads & processors either do not require signature capture or handle it themselves during an authorization.
  • /rest/pay/saveSignature
    • Used for saving a signature string, typically to a database. Currently unimplemented for all payment providers
  • /rest/pay/getCardDataRequired
    • Typically used to determine if the getCardData step is required prior to performing an authorization. Defaults to “required” for Aurus. Has been implemented for a different payment provider to help prevent purchasing gift cards with a gift card tender due to limitations of the payment provider. Unimplemented for Aurus/No Aurus implementation expected to be needed
  • /rest/pay/finalizePayment
    • Used to do “cleanup” after any authorization on a tender (update session ID, handle errors encountered). Unimplemented for Aurus/No Aurus implementation expected to be needed
  • /rest/pay/isVoidable
    • Determines if a transaction is voidable. Defaults to true. Unimplemented for Aurus/No Aurus implementation expected to be needed
  • /rest/pay/startup
    • Used for the ‘PaymentServiceStartupTask’ which can be run on startup of the server to perform any configuration the IPaymentService might require. Typically, and currently for Aurus, we have the payment service startup when a lifecycle event “RESTART” is fired, since that event will always be fired on startup and requires no further configuration, unlike what configuration a startup task might require.
  • /rest/pay/displayFinancingOptions
    • Typically a unique (but similar) implementation of ‘/rest/pay/displayScreen’, but specifically for ease of displaying financing options to the customer. Financing options can be configured for a specific sls_tender_model with a limit up to an specific tender_amount in the DB table ‘SLS_TENDER_FINANCING’.
  • /rest/pay/checkAuth
    • Used for authorizations of a check if the handling would be different from a standard authorization. Currently not needed for Aurus since other clients do not take check tenders
  • /rest/pay//returnAmountAvailable
    • Currently only implemented for 1 other payment provider. Amount remaining for return on each stored value return tender. See table ‘PAY_RETURN_TENDER’
  • /rest/pay/displayVirtualReceipt
    • Implemented for only 1 other payment provider. Transaction update events get fired and this endpoint will be called to attempt to format and display line items, subtotals, taxes, and grand total for the current transaction on the payment device. Can be further implemented to be payment device specific if needed.
  • /rest/pay/displayIdleScreen
    • A sister endpoint to ‘/rest/pay/displayVirtualReceipt’ intended to force taking down any currently displayed receipt on the payment device

Currently supported endpoints

Payments

  • /rest/pay/authorize
    • Authorizes funds for use from a customer’s account
  • /rest/pay/getCardData
    • Gathers card information, typically prior to an authorization, such that the POS can perform checks on the intended tender for authorization. This is typically used for checking if the customer is attempting to purchase a gift card with another gift card. Is also used generically so the POS can gather the card details and pass them directly into the next payment operation, such that any POS operation would only require 1 card swipe from the customer
  • /rest/pay/preAuthorize
    • Used for pre-authorizing funds to a credit card. Typically is just a $0 authorization. JMC will know if a previously used card was pre-authorized, and will allow this card to be reused
  • /rest/pay/returnAuth
    • Used for returning funds to a previously authorized. Does not need to be the same card necessarily.
  • /rest/pay/voidAuth
    • Used for voiding previously authorized funds (typically on a credit/debit card)

Gift card operations

  • /rest/pay/activateCard
    • Used for activating & loading a new gift card
  • /rest/pay/balanceInquiry
    • Used for informing the associate how much is on a loaded gift card. Will report if the card has no funds or is un-activated. Also used prior to performing a cashout to determine how much should be given in cash to the customer
  • /rest/pay/cashOut
    • Used for removing funds from an activated & loaded gift card
  • /rest/pay/reloadCard
    • Adding funds to an activated GC

Payment device

  • /rest/pay/cancel
    • Typically used for canceling in-progress payment operations (get card data, authorization). I believe this can be used to remove a customer prompt from the pinpad as well.
  • /rest/pay/diagnostics
    • Typically used by a background job running to determine current payment terminal information (firmware version, OS version, connection status). Aurus advertises in their documentation that battery level is reported for wireless devices, but have directly told us that battery level is not supported
  • /rest/pay/lifeCycleEvent
    • Current implementation registers the current payment terminal with the aurus service on server startup/client connection established (differing implementations for Windows and iOS)
  • /rest/pay/paymentConnected
    • Reports if the current payment device is connected. Disconnected may indicate the connection or pinpad itself is in an error state

Misc.

  • /rest/pay/options
    • Currently used to determine if the payment device supports prompting the customer (validate email, accept terms & conditions, etc.). Defaults to false.
  • /rest/pay/requiresMatchingCard
    • Used to determine if a tender operation requires a matching card to be used/swiped (typically for voids and refunds)