Add new payment method: Australian PayID

[mercurytoxic]

Australia PayID 🇦🇺

Summary

This PR adds support for Bisq trades using the Australian New Payments Platform (NPP)[1], known casually by everyone in Australia as "PayID".

• Country Restrictions: Australia only
• Currency Restrictions: AUD only
• Chargeback Risks: None, cannot reverse or chargeback
• Per-Trade Risk Limit: LOW (0.5 BTC * 2.0 multiplier = 1 BTC)
• Per-Trade Time Limit: DAY (transfers are near-instant, and 24/7/365 for major banks)

Overview

• A PayID is something easy to remember like a phone number, email address or an Australian Business Number (ABN), that you can securely link to your bank, credit union or building society account. Then when you want somebody to transfer funds into your account, you can give them your PayID instead of your BSB and account number. To pay another person’s PayID you just need to log into your participating financial institutions internet or mobile banking.[2]

• Transfers using PayID are usually near instant, compared to National Bank Transfers that in Australia usually take 1-2 business days for the deposits to clear. (Depends on individual bank policies, frequently first time transfers above a certain amount might have a 24 hour hold)

• A great number of Australian banks support PayID

Security

• Payments with PayID using NPP are made by logging into your usual online banking and authorizing a payment.
• When sending a payment using PayID you are able to check the name of the recipient before confirming the payment.
• Bank transfers are not reversible or chargeback-able

Privacy

• Only PayID and the recepient's name are shared.

How it works

• PayID is free to use.
• Transfers usually instant, but depending on the financial institutions that are used the first time a payment is made to a new PayID, the payment might be held for 24 hours.
• Available 24/7/365 since payments are electronic.

Account Information

To send a PayID transfer, the sender needs the following information:

• PayID
• Optional is the recepient's name to verify is the correct PayID account

Sending a Transfer

After the sender inputs the PayID in their online banking, the receiving account holder's name is displayed to the sender so they can verify they are sending funds to the correct account before they finalize the transaction.

The transfer is usually completed instantly, or on the next business day if it's the first time sending to a new PayID or one of the participating banks does not fully support PayID and depends on fallback BSB (routing) and account numbers.

Fraud Risks

• Since transfers are instant, a sender could transfer to a wrong account, but the ePayments code protects Australians from mistaken transfers. According to the code, the bank must endeavor to return your money to you as long as you notify them within 10 days.
• Transfers could be made from a stolen/hacked account. The owner of the account would have to notify their bank and follow their bank's procedures for this situation.

Therefore, the Australian PayID Transfer payment method is requested to be added with "LOW" risk setting, which limits each trade to 0.5 BTC by default, and after multiplying by the current DAO parameter (200%), this means Australian PayID Transfers will be limited to 1 BTC per trade at this time of this PR.

Footnotes

1. National Payments Platform https://nppa.com.au
2. PayID https://payid.com.au/ufaqs/what-is-a-payid/

Screenshots

Create Account

Form empty

Form Filled

Information/Confirmation popup

Display Account

Offer View

Maker view

Takers view

Trade in progress

Implementation Details

Input Validaton

Public methods emailvalidator else validatePhoneNumber

JSON contract payload

  "offerPayload": {
    "id": "KSBQB-0c7642a0-88ce-4422-9aa8-c88fbf32d1cb-127",
    "date": 1584495411861,
    "ownerNodeAddress": {
      "hostName": "vb4ny3e35fqz6fj4.onion",
      "port": 9999
    },
    "direction": "SELL",
    "price": 0,
    "marketPriceMargin": 0.1,
    "useMarketBasedPrice": true,
    "amount": 10000,
    "minAmount": 10000,
    "baseCurrencyCode": "BTC",
    "counterCurrencyCode": "AUD",
    "arbitratorNodeAddresses": [],
    "mediatorNodeAddresses": [
      {
        "hostName": "sjlho4zwp3gecspf.onion",
        "port": 9999
      }
    ],
    "paymentMethodId": "AUSTRALIA_PAYID",
    "makerPaymentAccountId": "d1fd3df6-2f69-4946-a2c4-37572ff4bbc1",
    "offerFeePaymentTxId": "655f5e1e526cc56b1b7d37bed79ad687f2041246905f563d030c2afce57b51a5",
    "versionNr": "1.2.7",
    "blockHeightAtOfferCreation": 622032,
    "txFee": 3120,
    "makerFee": 5000,
    "isCurrencyForMakerFeeBtc": true,
    "buyerSecurityDeposit": 600000,
    "sellerSecurityDeposit": 600000,
    "maxTradeLimit": 25000000,
    "maxTradePeriod": 86400000,
    "useAutoClose": false,
    "useReOpenAfterAutoClose": false,
    "lowerClosePrice": 0,
    "upperClosePrice": 0,
    "isPrivateOffer": false,
    "extraDataMap": {
      "capabilities": "0, 1, 2, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14",
      "accountAgeWitnessHash": "75161336216a603badc768f9b856647c4b6c1ece"
    },
    "protocolVersion": 2
  },
  "tradeAmount": 10000,
  "tradePrice": 96592760,
  "takerFeeTxID": "6fcd82105f1391bb6a615e7de033df6aabb8d827e3c34e298115383eee4a4434",
  "buyerNodeAddress": {
    "hostName": "t52a2sr3l6t5wxpm.onion",
    "port": 9999
  },
  "sellerNodeAddress": {
    "hostName": "vb4ny3e35fqz6fj4.onion",
    "port": 9999
  },
  "mediatorNodeAddress": {
    "hostName": "sjlho4zwp3gecspf.onion",
    "port": 9999
  },
  "isBuyerMakerAndSellerTaker": false,
  "makerAccountId": "477030286",
  "takerAccountId": "1368213156",
  "makerPaymentAccountPayload": {
    "payid": "pizzaman@hotmail.com",
    "bankAccountName": "Luis Aranguren",
    "paymentMethodId": "AUSTRALIA_PAYID",
    "id": "d1fd3df6-2f69-4946-a2c4-37572ff4bbc1",
    "maxTradePeriod": -1
  },
  "takerPaymentAccountPayload": {
    "payid": "0401014933",
    "bankAccountName": "Luis Aranguren",
    "paymentMethodId": "AUSTRALIA_PAYID",
    "id": "5ddadab2-5ead-4961-bec8-2f8200699d12",
    "maxTradePeriod": -1
  },
  "makerPayoutAddressString": "1FJgJA9hkf3q44SwUbuiEo4ahzt6XyUBPf",
  "takerPayoutAddressString": "12FPeknpbbu6ik5g3BRV5UF9CVB24gDqz3",
  "lockTime": 624941,
  "refundAgentNodeAddress": {
    "hostName": "xnjz5nq5gifju4zb.onion",
    "port": 9999
  }
}

BuyerMultiSigPubKeyHex: 03a04172f577163aca9b1cd3c0a659d668bccf823b28160ba475f6347a1ff7ffb4
SellerMultiSigPubKeyHex: 03a749b6dce055aef95f8ae933cb6a51acea06343d8d2ff2070c29324a0ab934ce
BuyersAccountAge: Payment account created 1 day ago.
SellersAccountAge: Payment account created 1 day ago.

[boring-cyborg]

Thanks for opening this pull request!

Please check out our contributor checklist and check if Travis or Codacy found any issues with your PR. Also make sure your commits are signed, and that you applied Bisq's code style and formatting.

A maintainer will add an is:priority label to your PR if it is up for compensation. Please see our Bisq Q1 2020 Update post for more details.

[wiz]

Thanks for your PR and for using the Japan bank transfer as a template. I haven't looked at the code yet, but my initial thoughts are mostly about this claim:

Bank transfers are not reversible or chargeback-able

Later in the PR you have:

Transfers could be made from a stolen/hacked account. The owner of the account would have to notify their bank and follow their bank's procedures for this situation. According to the code, the bank must endeavour to return your money to you as long as you notify them within 10 days.

These statements seem to completely contradict each other. In any case, citation needed for the "not reversible" claim, as it's the most important thing used to evaluate the risk of the payment method.

[m52go]

Keep in mind chargebacks being possible isn't the end of the world...if possible, they should just be very difficult.

In such cases, the payment method can still be added to Bisq, but it will require account signing to lift 0.01 BTC limits.

So to proceed we need more clarity and detail about where this payment method really stands with respect to chargeback.

[ripcurlx]

@mercurytoxic As mentioned by the boring-cyborg please have a look at the Codacy issues: https://app.codacy.com/gh/bisq-network/bisq/pullRequest?prid=5213489 Thanks!

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.

[stale]

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.

[wiz]

@m52go @ripcurlx any objection to just merging this and trying it out for a while?

[ripcurlx]

There have been codacy issue that need to be addressed. If we want to test it I can take care of fixing them. Re-opening the PR now for discussion.

[wiz]

I don't think the author of the PR is coming back, so if you could just fix it so it gets merged that would be great. Then I can ask some friends in Australia to start testing it on master

[mercurytoxic]

Thanks for your PR and for using the Japan bank transfer as a template. I haven't looked at the code yet, but my initial thoughts are mostly about this claim:

Bank transfers are not reversible or chargeback-able

Later in the PR you have:

Transfers could be made from a stolen/hacked account. The owner of the account would have to notify their bank and follow their bank's procedures for this situation. According to the code, the bank must endeavour to return your money to you as long as you notify them within 10 days.

These statements seem to completely contradict each other. In any case, citation needed for the "not reversible" claim, as it's the most important thing used to evaluate the risk of the payment method.

As per this a chargeback is a mechanism used by financial institutions to revert transactions made with credit and debit cards. Since PayID is effectively a bank transfer, the term and procedure doesn't apply.

What can de done is a dispute. Just like a bank transfer there are policies in place, that slightly change from bank to bank, to report and open disputes. This will include submitting information to the sending bank, then sending bank contacting the receiving bank which will launch it's own investigation. This process is not automated and usually takes several weeks. Receiving bank and/or recepient has to agree to return the funds.

Effectively, PayID transfers are similar in risk as bank transfers.

[m52go]

any objection to just merging this and trying it out for a while?

Sure. I remember another Australian user was positive about PayID back when this PR was opened. But we need to figure out how to handle signing, since we haven't introduced any new payment methods since signing was implemented.

Since PayID transfers are similar in risk as bank transfers, as @mercurytoxic says above, and AUD is a market that requires signing, this new payment method should require signing too. But the payment method needs time to bootstrap itself first. So it cannot have signing immediately in its first release.

@sqrrm is it possible to temporarily exclude a risky payment method in a market where signing is required? Maybe this is something we could address with your proposal on defining trade limits.

[wiz]

Receiving bank and/or recepient has to agree to return the funds.

If that is true then the chargeback risk is LOW

[ripcurlx]

Since PayID transfers are similar in risk as bank transfers, as @mercurytoxic says above, and AUD is a market that requires signing, this new payment method should require signing too. But the payment method needs time to bootstrap itself first. So it cannot have signing immediately in its first release.

If we have a user that has a signed account and uses the same name on Australian PayID his/her account will be automatically self-signed. That could be our way to bootstrap account signing.

[wiz]

Nah, account signing sucks. Just let them use bank transfer payment method without signing since the risk of chargeback is low. If we have problems THEN we can require the signing.

[ripcurlx]

@sqrrm is it possible to temporarily exclude a risky payment method in a market where signing is required? Maybe this is something we could address with your proposal on defining trade limits.

At the moment the chargeback risk is checked by the combination of currency and payment method. So you can have a payment method (e.g. Australian PayID) in a "mature" market. Unfortunately if we would mark a payment method as one with a chargeback risk later to require account signing, this would render all existing offers invalid.

[ripcurlx]

@mercurytoxic As I saw you forced push to this branch. I checked the Codacy complaints and remove the patterns that we don't need to enforce. Still there are unnecessary ; in the imports. Please see https://app.codacy.com/gh/bisq-network/bisq/pullRequest?prid=5213489

Also you need to resolve the conflicts with master above to make the PR mergable. Thanks!

[sqrrm]

@ripcurlx I think it wouldn't be too hard to add a per payment method check for signing required or not. The less signing needed the better for everyone. Transition from a no signing needed to it being needed might be not so smooth, but I would rather try it out without first and hopefully never need the signing.

[chimp1984]

@sqrrm @ripcurlx What is with that PR? Still relevant? If conceptual issues maybe @pazza85 can help... (have not read discussions here)

[ripcurlx]

@sqrrm @ripcurlx What is with that PR? Still relevant? If conceptual issues maybe @pazza85 can help... (have not read discussions here)

It is still relevant. Just needs some code clean-up and code merging. I probably do it myself to get it into the v1.5.0 release.

[ripcurlx]

Superseded by #4742

[apemithrandir]

I would like to suggest that the PayID maxTradePeriod be increased from 86400000 ms to 172800000 ms (48 hours). This is because around 25% of the time banks like to put a 24 hour hold on PayID payments to new recipients. Having the PayID maxTradePeriod at exactly 24 hrs leads to more mediations under this circumstance.

If the bank puts no hold on the payment then the payment is received within 1 minute, if the bank puts a hold on it the payment will be received within 24 hours of it being made. When the bank puts a hold in place one should expect the trading period to be around 36 hours on average (assuming it takes half a day for the trader to notice they have traded and initiate the payment).