Currently I am storing the 'Id' value returned by Balanced.js as the card/bank account token.
Then I suffix that with the API URI (/v1/marketplaces/TEST-MP5..../cards/) to charge cards.
Do I need to store the entire uri returned by Balanced.js ? What are the chances that stored URI prefix (/v1/...) will be changed in the future ?
What is the difference between the two end points for bank accounts? (cards seem to have only one uri: always prefixed with /v1/marketplaces..)
but bank accounts - looks like you can access the via:
/v1/bank_accounts/BA.... or
/v1/marketplaces/TEST-.../bank_accounts/BA...
Even the documentation differs for both. Why can't they be done consistently ?
https://docs.balancedpayments.com/current/api.html?language=php#adding-a-card-to-a-customer
Cards are added with:
$customer->addCard("/v1/marketplaces/TEST-MP.../cards/CC...")
https://docs.balancedpayments.com/current/api.html?language=php#adding-a-bank-account-to-a-customer
Bank accounts are added with
$customer->addBankAccount("/v1/bank_accounts/BA..")
Inconsistent documentation is confusing.. Thanks
You should always store the entire URI, constructing your own URI
from the ID can lead to conflicts with future API revisions.
There's no difference between the bank accounts. You may retrieve bank accounts from those endpoints. They will both result in the same bank accounts. There's some slight usability difference in both of them, but they're the same resource.
Related
I have questions about:
fungible Token example and NEP-21 itself.
It's a possible situation when escrow allowances > 0, but account balance = 0.
Is it legal flow and why?
It never checks account_id exists or not. Why? Is it secure?
Anyone can call: inc_allowance/dec_allowance?
And for let owner_id = env::predecessor_account_id(); will be created new account, new escrow allowance automatically (if not exist). Is that logic correct and why?
get_account always created a new account. It looks redundant.
For example:
fn get_account(&self, owner_id: &AccountId) -> Account {
assert!(env::is_valid_account_id(owner_id.as_bytes()), "Owner's account ID is invalid");
let account_hash = env::sha256(owner_id.as_bytes());
self.accounts.get(&account_hash).unwrap_or_else(|| Account::new(account_hash))
}
Will create "always" new account for new owner_id. And it's possible then that account will never be used. So is it really practical to silently "create" an account with get_account?
transfer_from is never check owner_id as the real owner of the account. Is there logic to protect transferring only by real owners?
Why fungible token doesn't have a name/title?
Do the NEAR Protocol have some standard or logic for Fungible Tokens exchange?
It's a possible situation when escrow allowances > 0, but account balance = 0. Is it legal flow and why?
AFAIU allowance is just a sanity upper bound that prevents abuse. Two accounts can have two allowance for the same account that together sum up to a number larger than account balance.
It never checks account_id exists or not. Why? Is it secure?
In a sharded blockchain it is impossible to check for account existence without an asynchronous cross-contract call, since that other account might live on a different shard. Additionally, by the time we get a reply from that other shard this account can be created/deleted.
Anyone can call: inc_allowance/dec_allowance?
It can be only called by the owner, see: https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L106
And for let owner_id = env::predecessor_account_id(); will be created new account, new escrow allowance automatically (if not exist). Is that logic correct and why?
Yes. I am not sure, why this would be contradictory.
get_account always created a new account. It looks redundant.
It might be redundant, but it also might be optimized out by the compiler in situations like this one: https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L213
transfer_from is never check owner_id as the real owner of the account. Is there logic to protect transferring only by real owners?
It is implied in this check: https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L174-L180 If it is not the case of an escrow, then env::predecessor_account_id() should be equal to owner_id. So the receipt/transaction must have been sent from the account of the owner.
Why fungible token doesn't have a name/title?
We are working on adding metadata to our contracts, see our Q1 OKRs here: https://airtable.com/shrw0AD36eIbfEW02
Do the NEAR Protocol have some standard or logic for Fungible Tokens exchange?
We have partners working on implementing something similar, but I don't think we have a standard.
I am looking for specific meaning of following fields
valueIdentifier
valueMask
fieldType
FieldInfoMultiFixed
AutoRegFieldInfoSingle
FieldInfoMultiVariable
and in most cases we are getting numerical value for helpText. How do we identify whether helpText is present or not?
A lot of the stuff like FieldInfoMultiFixed/Variable is discussed in the Yodlee SDK Developer guide. Search for either one. They're just basically silly combos where people breakup a single value into multiple fields (like phone number or ssn into 3 textboxes)
As for the helpText, every time i've seen a Yodlee tech respond they say no. The number corresponds to an internal resource identifier that is apparently not exposed through the api. I want to say I saw somebody say that it might be available for things like forum signup/registration (where it would be more useful). The SDK makes mention as if it works as you would expect it to but that is an error.
Currently Yodlee does not have helptext populated for any field. Hence a numerical value is associated to it. In future if any helptext gets added then instead of numerical value you will have text in that field.
Hence if you are receiving numerical values then you should take it as helptext not present.
Shreyans
I've gone through a number of pages and PDFs within the Paypal guides and x.com, but I can't find any reference to the maximum field lengths for the API login/connection. I see the Transaction ID maxes out at 19 characters, but they seem to avoid saying the maximums for the access fields.
I'm setting up a database table to hold multiple Paypal API logins as well as a section to edit it with I'll have validate by length. I want to use some real values instead of guessing 255 characters.
Surely someone must have been as specific as me in this regard, I'm hoping someone has found this answer.
I've always gone with 75 and that seems to be safe.
On the NVP API Method and Field Reference page at http://www.paypalobjects.com/en_US/ebook/PP_NVPAPI_DeveloperGuide/Appx_fieldreference.html they indicate EMAIL as "127 single byte characters".
As for the other items, I did not see any documented lengths, but checking 5 client accounts, it appears that
API PWD is 16 characters
API signature is 56 characters - in each account (these must be fixed length).
Has anyone come up with an elegant way to search data stored on Authorize.net's Customer Information Manager (CIM)?
Based on their XML Guide there doesn't appear to be any search capabilities at all. That's a huge short-coming.
As I understand it, the selling point for CIM is that the merchant doesn't need to store any customer information. They merely store a unique identifier for each and retrieve the data as needed. This may be great from a PCI Compliance perspective, but it's horrible from a flexibility standpoint.
A simple search like "Show me all orders from Texas" suddenly becomes very complicated.
How are the rest of you handling this problem?
The short answer is, you're correct: There is no API support for searching CIM records. And due to the way it is structured, there is no easy way to use CIM alone for searching all records.
To search them in the manner you describe:
Use getCustomerProfileIdsRequest to get all the customer profile IDs you have stored.
For each of the CustomerProfileIds returned by that request, use getCustomerProfileRequest to get the specific record for that client.
Examine each record at that time, looking for the criterion you want, storing the pertinent records in some other structure; a class, a multi-dimensional array, an ADO DataTable, whatever.
Yes, that's onerous. But it is literally the only way to proceed.
The previously mentioned reporting API applies only to transactions, not the Customer Information Manager.
Note that you can collect the kind of data you want at the time of recording a transaction, and as long as you don't make it personally identifiable, you can store it locally.
For example, you could run a request for all your CIM customer profile records, and store the state each customer is from in a local database.
If all you store is the state, then you can work with those records, because nothing ties the state to a specific customer record. Going forward, you could write logic to update the local state record store at the same time customer profile records are created / updated, too.
I realize this probably isn't what you wanted to hear, but them's the breaks.
This is likely to be VERY slow and inefficient. But here is one method. Request an array of all the customer Id's, and then check each one for the field you want... in my case I wanted a search-by-email function in PHP:
$cimData = new AuthorizeNetCIM;
$profileIds = $cimData->getCustomerProfileIds();
$profileIds = $cimData->getCustomerProfileIds();
$array = $profileIds->xpath('ids');
$authnet_cid = null;
/*
this seems ridiculously inefficient...
gotta be a better way to lookup a customer based on email
*/
foreach ( $array[0]->numericString as $ids ) { // put all the id's into an array
$response = $cimData->getCustomerProfile($ids); //search an individual id for a match
//put the kettle on
if ($response->xml->profile->email == $email) {
$authnet_cid = $ids;
$oldCustomerProfile = $response->xml->profile;
}
}
// now that the tea is ready, cream, sugar, biscuits, you might have your search result!
CIM's primary purpose is to take PCI compliance issues out of your hands by allowing you to store customer data, including credit cards, on their server and then access them using only a unique ID. If you want to do reporting you will need to keep track of that kind of information yourself. Since there's no PCI compliance issues with storing customer addresses, etc, it's realistic to do this yourself. Basically, this is the kind of stuff that needs to get flushed out during the design phase of the project.
They do have a new reporting API which may offer you this functionality. If it does not it's very possible it will be offered in the near future as Authnet is currently actively rolling out lots of new features to their APIs.
I cannot get the Flickr API to return any data for lat/lon queries.
view-source:http://api.flickr.com/services/rest/?method=flickr.photos.search&media=photo&api_key=KEY_HERE&has_geo=1&extras=geo&bbox=0,0,180,90
This should return something, anything. Doesn't work if I use lat/lng either. I can get some photos returned if I lookup a place_id first and then use that in the query, except then all the photos returned are from anywhere and not the place id
Eg,
http://api.flickr.com/services/rest/?method=flickr.photos.search&media=photo&api_key=KEY_HERE&placeId=8iTLPoGcB5yNDA19yw
I deleted out my key obviously, replace with yours to test.
Any help appreciated, I am going mad over this.
I believe that the Flickr API won't return any results if you don't put additional search terms in your query. If I recall from the documentation, this is treated as an unbounded search. Here is a quote from the documentation:
Geo queries require some sort of limiting agent in order to prevent the database from crying. This is basically like the check against "parameterless searches" for queries without a geo component.
A tag, for instance, is considered a limiting agent as are user defined min_date_taken and min_date_upload parameters — If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future).
My app uses the same kind of geo searching so what I do is put in an additional search term of the minimum date taken, like so:
http://api.flickr.com/services/rest/?method=flickr.photos.search&media=photo&api_key=KEY_HERE&has_geo=1&extras=geo&bbox=0,0,180,90&min_taken_date=2005-01-01 00:00:00
Oh, and don't forget to sign your request and fill in the api_sig field. My experience is that the geo based searches don't behave consistently unless you attach your api_key and sign your search. For example, I would sometimes get search results and then later with the same search get no images when I didn't sign my query.