What's better: return null or handle the Exception? I'm in doubts what approach to take here, please have a look on the code below:

private void processBarCodeResponse(String decodedQrCode) {
        JSONObject jsonObject = JsonUtil.composeJsonObject(decodedQrCode);
        SalePoint salePoint = parseSalePoint(jsonObject);
        if (salePoint == null) return; // handle null value here
        saveSalePoint(salePoint);
    }

private SalePoint parseSalePoint(JSONObject jsonObject) {
        SalePoint salePoint = new SalePoint();
        try {
            salePoint.type = jsonObject.getString("type");
            salePoint.url = jsonObject.getString("url");
            salePoint.salePointId = jsonObject.getString("salePointId");
        } catch (JSONException e) {
            Logger.logError(TAG, "jsonObject " + jsonObject.toString() + " wasn't parsed " +
                    "correctly");
            return null; // point of concern
        }

        return salePoint;
    }


For the sake of readability I moved the try/catch block to the parseSalePoint() method, but then if parsing fails I'm enforced to return null from the method and check for null value in processBarCodeResponse() method. Wouldn't it be right to just handle the JSONException in processBarCodeResponse() method and stop its execution once it is thrown?
A possibly useful pattern here can be the Null Object-pattern.

Instead of returning null, return a "null SalePoint". Perhaps something like new SalePoint();, or new SalePoint("some special url");. Then make your saveSalePoint method do nothing if the SalePoint has a special url indicating that it's null. 

Another option is to return null from your parseSalePoint method as you are currently doing and then simply return from the saveSalePoint method if the argument is null which will remove the null check from processBarCodeResponse.

Honestly, I can't tell you which option you should use or not. I can only present you with alternatives. Personally I like Null Object pattern a lot, but it doesn't always makes much sense to use that pattern.

By the way, why isn't SalePoint immutable? Instead of first creating a SalePoint object and then setting it's values one by one, read the values into variables and call a constructor which takes type, url, salePointId as arguments and get rid of the accessible properties (make them private, and also get rid of the setter-methods if you have any)