balanced / balanced-java Goto Github PK

Add API call to update users Account information (e-mail, postal_code, etc.) via PUT request..

I may get to this myself but wanted to capture the request

See balanced/balanced-api#514 for detail.

Both BankAccount and Account are doing this:

    if (destination_uri != null)
        payload.put("destination", destination_uri);

...when I believe it should be this:

    if (destination_uri != null)
        payload.put("destination_uri", destination_uri);

Operate on generic FundingInstrument instances instead of on specific subclasses. For example, allow crediting to a FundingInstrument instead of only to a BankAccount. See here for context.

The api now supports setting the default card and bank account by PUTing to the source_uri and destination_uri. Then the default source will be represented by the value of source_uri and destination_uri.

https://github.com/balanced/balanced-java/blob/master/src/main/java/com/balancedpayments/Customer.java#L115

Currently in balanced-java, the Hold object has an appears_on_statement_as field. Unless I've been misinformed, that field only applies to a hold when it gets captured as a debit. And it's not technically a field on hold at all...it's a parameter in the capture/debit creation payload.

And it is a field on Debit, which is currently lacking that field in balanced-java.

I suggest that we remove Hold.appears_on_statement_as, and instead make it an optional argument to Hold.capture().

And regardless, we should add the Debit.appears_on_statement_as field.

I'm volunteering to do this work...I'm not, however, aware of how extensively the community is already using Hold.appears_on_statement_as. But to be honest, I can't see how it ever functioned in a useful way, so something tells me we could deprecate it for a version and then yank it. :-)

Balanced has released revision 1.1 of the API. Please upgrade the java client to support this revision.

something i can run from cmd line just like the other clients (e.g. https://github.com/balanced/balanced-php/blob/master/example/example.php)

I think the current lack of this was just an oversight. :-)

This is happening intermittently. When we try to capture a previously created hold (created a few minutes prior to the capture attempt), we're getting this NullPointerException.

java.lang.NullPointerException
        at com.balancedpayments.core.Client.error(Client.java:205)
        at com.balancedpayments.core.Client.op(Client.java:181)
        at com.balancedpayments.core.Client.post(Client.java:102)
        at com.balancedpayments.core.ResourcePagination.create(ResourcePagination.java:93)
        at com.balancedpayments.CardHold.capture(CardHold.java:77)

The line of code is in Client.java:

    Map<String, Object> entity = (Map<String, Object>)((ArrayList)payload.get("errors")).get(0);

The problem appears to be that there is no "errors" array in the payload.

balanced-java should probably handle this more gracefully.

And the Balanced API obviously has some sort of bug, which I'll address separately.

src/main/java/com/balancedpayments/core/Client.java
44: private static final String VERSION = "0.10";

Also while you're at it please fix Debit(String uri) constructor which is supposed to call super(uri).

Currently, the payload map is just discarded after being used to deserialize an object. I think there are huge benefits to storing it within the object it was used to deserialize.

It would allow access to fields not explicitly exposed by the version of the Java API being used. For example, as of 0.10-SNAPSHOT, we cannot yet determine the type of a FundingInstrument. However, with the payload map, we can do the following:

String debitUri = "...";
Debit debit = new Debit(debitUri);
FundingInstrument source = debit.source;
// Presuming the payload map will be stored as a _payload field
String type = (String) source._payload.get("_type");
switch (type) {
    case "bank_account":
        break;
    case "card":
        break;
}

custom annotations

see https://github.com/balanced/balanced-php/blob/master/src/Balanced/Account.php#L92

Accounts.java has several places 1, 2 where it references the source_uri param as source which will result in the param being ignored.

We should

1. Fix these.
2. Write test cases to ensure that the server is receiving the expected result and honoring it.

We have a new Customer resource.

With a customer you should be able to debit, credit, as well as add_card and add_bank_account. A customer should be able to tell you their active_card and active_bank_account.

the category_code "card-declined" is not part of the code that would result in a Declined exception being thrown. (java 1.1 api)

http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#format

https://github.com/balanced/balanced-docs/

None of those exceptions implements message, so logging the exception as is provides no useful information as a default.

It forces to wrap all calls and log + convert the exception into something more abstracted that is logging friendly (for example the list of the important attribute concatenated into a readable string to be used as the message).

Callbacks and Events

I'm new...so forgive me if I'm missing something, but Customer.java and Account.java both do this in some of their hold() and debit() methods:

    if (source_uri != null)
        payload.put("source", source_uri);

I believe it should use "source_uri" instead of "source". Reference:

https://docs.balancedpayments.com/current/api#create-a-new-hold

Given the payload

{
    "debits": [
        {
            "amount": 5000, 
            "appears_on_statement_as": "BAL*Statement text", 
            "created_at": "2014-02-27T20:03:06.176697Z", 
            "currency": "USD", 
            "description": "Some descriptive text for the debit in the dashboard", 
            "failure_reason": null, 
            "failure_reason_code": null, 
            "href": "/debits/WD1l5vYA21ZP24LMQMqHizea", 
            "id": "WD1l5vYA21ZP24LMQMqHizea", 
            "links": {
                "customer": null, 
                "dispute": null, 
                "order": null, 
                "source": "CC1diaA1Lunr4RlelwKQ8C4v"
            }, 
            "meta": {}, 
            "status": "succeeded", 
            "transaction_number": "W347-910-8642", 
            "updated_at": "2014-02-27T20:03:07.629780Z"
        }
    ], 
    "foos": [
        {
        }
    ], 
    "links": {
        "debits.customer": "/customers/{debits.customer}", 
        "debits.dispute": "/disputes/{debits.dispute}", 
        "debits.events": "/debits/{debits.id}/events", 
        "debits.order": "/orders/{debits.order}", 
        "debits.refunds": "/debits/{debits.id}/refunds", 
        "debits.source": "/resources/{debits.source}"
    }
}

Make sure that this client library does not choke and return the wrong object.

The Java library (v0.10) currently doesn't support the Play framework.

When attempting to use it as a Play plugin, simple calling "new Marketplace()" returns an APIError from Client.java without making a network request. I suspect that the networking client you're using is incompatible with Play's web service interface.

Please advise if the Play Framework is on the roadmap.

In #36 a bug was uncovered where we return a generic FundingInstrument object instead of creating a BankAccount or Card object based on the type of payload.

If we inspected the payload's _type property when it's available we could construct the correct object rather than using the generic type.

http://stackoverflow.com/a/12268644/789610.

https://github.com/balanced/balanced-java/blob/master/src/main/java/com/balancedpayments/core/Resource.java#L24-L26

Perhaps push to the nexus repo on successful build automatically?

From nginx's access logs:

"POST /v1/marketplaces HTTP/1.1" 201 2191 "-" "balanced-java/null" 0.503 "OHM96798f327a0211e2ba86026ba7f8ec28"

For additional fraud risk analysis it is customary to use the BIN of the credit card for analysis. Right now the BIN is not provided by the API when fetching the card information and it prevents us to provide this information to additional third party.

This is incredibly low priority, but it stuck out to me as a common misunderstanding of how org.junit.Assert.assertEquals is supposed to be used. The "expected" value is supposed to be passed as the first argument, but the balanced-java unit tests consistently reverse the args. This means when a unit test fails, you will actually see a misleading error message.

I'm volunteering to fix this...

Unless I'm misreading the API docs, Hold needs a "source" field. Looks like we can probably do what Debit does, which is:

@ResourceField(required=false)
public FundingInstrument source;

I'm not sure about required=false or true...somebody in the know should probably confirm.

I'm starting to think balanced-java has just been left by the wayside... :-)

Balanced now support ACH Debits. Let Java folk use them!

Fetching the Credit description is always null. I think this is due to the deserialize method in the Credit.java. Note the extra space in the get method call.

~line 52 Credit.java

description = (String) payload.get("description ");

Also create a promoteToMerchant method on the Account object

The bank name is being sent back in the json response, but it is not exposed in the current Java 1.1 API. It would be great to expose this information so that it can be captured and used either for statistical analysis or for customer support.

It would be suitable to include and repackage the dependencies (aka relocating classes) that the client depends (gson, commons httpclient/codec/lang, joda) to avoid clashing with the versions the application may use. (eg. our application may use a version that is incompatible with the balanced one and vice-versa)

This can be achieved with the maven shade plugin.

Just ran across this while testing my app. It appears there is a single static SimpleDateFormat member variable of the Resource class. Unfortunately, SimpleDateFormat is not thread safe. Specifically, if you have two Resources being deserialized on two concurrent threads, they will clash over that SimpleDateFormat instance, and both threads are gonna have a bad time. In other words, this library will currently not work at all in a multi-threaded environment. The exception that brought it to my attention during testing was:

Caused by: java.lang.NumberFormatException: multiple points

This is just one of a few types of exceptions that can occur from this issue. I took the liberty of finding a good StackOverflow answer that explains it further for your reference:

http://stackoverflow.com/questions/4021151/java-dateformat-is-not-threadsafe-what-does-this-leads-to

Your best bet for correcting this is probably going to be the use of a ThreadLocal as seen in the third ConcurrentDateFormatAccessExample here:

http://www.javacodegeeks.com/2010/07/java-best-practices-dateformat-in.html

EDIT: The issue appears to exist also in ResourceQuery.

The order_by method should take an enum instead of a boolean.

e.g.

collection.query.order_by('created_at', SortOrder.Descending);

The API allows for the deletion of Customers "so long as there has been no activity associated with it such as creating a hold, credit, or debit"

This ability needs to be added.