remote-pay-android | Clover SDK for Android PoS Integration

by clover Java Version: v4.3.5 License: No License

X-Ray Key Features Code Snippets Community Discussions(2)Vulnerabilities Install Support

kandi X-RAY | remote-pay-android Summary

remote-pay-android is a Java library. remote-pay-android has no bugs, it has no vulnerabilities, it has build file available and it has low support. You can download it from GitHub, Maven.

This SDK allows your Android-based Point-of-Sale (POS) system to communicate with a Clover payment device and process payments. Learn more about Clover Integrations.

Support

Quality

Security

License

Reuse

Support

remote-pay-android has a low active ecosystem.

It has 14 star(s) with 14 fork(s). There are 28 watchers for this library.

It had no major release in the last 12 months.

remote-pay-android has no issues reported. There are 2 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of remote-pay-android is v4.3.5

Quality

remote-pay-android has no bugs reported.

Security

remote-pay-android has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

License

remote-pay-android does not have a standard license declared.

Check the repository for any license declaration and review the terms closely.

Without a license, all rights are reserved, and you cannot use the library in your applications.

Reuse

remote-pay-android releases are available to install and integrate.

Deployable package is available in Maven.

Build file is available. You can build the component from source.

Top functions reviewed by kandi - BETA

kandi has reviewed remote-pay-android and discovered the below as its top functions. This is intended to give you an instant insight into remote-pay-android implemented functionality, and help decide if they suit your requirements.

Handle a message
Handles a command
Sends PONG
Notify all registered observers of ack
Initialize the USB device
Determine if the specified USB device matches the given vendors
Connect the USB device
Creates an intent filter that allows to receive messages
Handle the receive device
Requests that the device has been granted
Method used to void VoidPayment
Obtains the transport that will be used for the Remote Pay Display
Connects the remote terminal
Process the remote string
This method is called before the request is received
Called when a USB service is destroyed
Sales a sale request
Receives a PairingMessage
Process input data
Method for ManualRefund
Initializes the connection
Handles USB command
Capture preauth request
Create a trust store from a resource
Reads card data
Authenticate with the Request

Get all kandi verified functions for this library.

remote-pay-android Key Features

No Key Features are available at this moment for remote-pay-android.

remote-pay-android Examples and Code Snippets

No Code Snippets are available at this moment for remote-pay-android.

Community Discussions

Trending Discussions on remote-pay-android

Getting Transaction Declined for sale transaction

Running into LinearAlloc overflows midway through integration tests

QUESTION

Getting Transaction Declined for sale transaction

Asked 2020-Apr-21 at 05:39

We are working on an Apache Cordova plugin based on remote-pay-android-go SDK that will allow Ionic/Cordova applications to integrate with the Clover Go device.

Here is the link to the plugin. We have implemented basic methods to init, connect, disconnect and make a sale. We are getting the error message "Transaction Declined. Please use another form for Payment" with reason "charge_declined", whenever we perform sale through the device.

I tried the example code in the remote-pay-android-go SDK and the code gives the same error for sale from the device and works well for the manual transaction.

Can someone help me understanding where we may be missing?

Thanks in advance!

...

ANSWER

Answered 2020-Apr-21 at 05:39

I was able to get past this by following a recent answer by David Marginian on the Clover forum.

Source https://stackoverflow.com/questions/61265496

QUESTION

Running into LinearAlloc overflows midway through integration tests

Asked 2020-Mar-02 at 11:36

This is for a largish 3-4 year running Android project, running on Gradle 5.4.1. Integration testing is with Mockito, espresso and dagger.

I have run into an issue where we are adding a Pendo library to the project, the dependency was added to Gradle as standard. Everything runs fine, until we try to run integration tests (~2000), these are run in shards with Spoon.

Around half way through the integration tests, on random tests each time, we run into a native crash killing the test run, due to LinearAlloc exceeding capacity. Running these tests in isolation, or in their classes locally they pass with no issues and have been stable for a long time.

I brought the whole app back to the known good build, added the Pendo dependency only and this results in the same problem, however I don't believe this is due to Pendo, as I tested by coming back to a known good build (tested on again at this point for sanity) and adding a random new dependency, this resulted in the same problem.

From what I can find this may be something to do with the method limits around Android. I should mention we are using multidex to break the app down. Proguard and minify are also being used.

Part of the issue here is that I'm really not sure what to look at to figure out what's going on to cause this overflow. Following the logs for the test runs, nothing appears to be amiss, bar a fair bit of garbage collection (which I'm guessing means a leak somewhere). I'm unsure if this issue is down to some underlying leak, and the new libraries are pushing something just over the edge, or if there's some dependency limit in android that I'm unaware of, or some other way to break the files down so we aren't causing LinearAlloc to fill up.

From reading, I know the limits of LinearAlloc were upped around Android 5, we are having problems on devices both above (Android 10) and below this (Android 4) and I don't really see much chat around this since 2017, so I feel like I'm missing something obvious, or something is misconfigured in the project given it was setup before then.

Any help would be really appreciated. I've dumped a cut down version of the gradle file below

...

ANSWER

Answered 2020-Mar-02 at 11:36

Okay so this was a fun one, leaving this up incase anyone ever runs into a similar issue.

It seems in this case, the error message we were getting out was fairly misleading. A good way to help diagnose these sort of errors is to look at the tombstone left by the crash, see https://source.android.com/devices/tech/debug/native-crash for more info around that

In this case proguard was our enemy, it seemed to be performing some sort of optimisation on the test code leading to variables being assigned incorrectly and was resolved by adding -optimizations *other optimizations*,!code/allocation/variable this might not work for your particular case, but maybe try configuring proguard to do no optimisation and see if that helps :D

Source https://stackoverflow.com/questions/60420269

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install remote-pay-android

You can download it from GitHub, Maven.
You can use remote-pay-android like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the remote-pay-android component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: