i need help solving this using Anchor Framework. can anyone help? thanks :D
Write test cases to prove that the contract is functioning as expected in anchor.Write sample program with the following specs:
State variables:
Merchant
Buyer
Price
Constructor:
Can be initiated only by the merchant
Pricing function:
Create price of product
Pay:
Calculate current gas fees on blockchain.
Add current gas to price of product.
Take payment from msg.
Withdraw:
Let ONLY merchant withdraw the proceeds of sales from the contract to his wallet.
Write test cases to prove that the contract is functioning as expected in anchor.
Related
I'm currently looking into Cybersource's REST API for the tokenization of cards.
Reference: https://developer.cybersource.com/api-reference-assets/index.html#token-management
However, I'm having some trouble wrapping my head around the following and could use some advice from those who have already worked with Cybersource and are more familiar with the terminology.
Under Token Management, there's an Instrument Identifier and Payment Instrument.
Instrument Identifier seems to return the same unique ID for the same card and is part of the overall Payment Instrument token.
If I POST (create) a Payment Instrument token, inside the response, I see that as well, where an Instrument Identifier is returned and giving me back the same id as long as the card is the same.
However, the Payment Instrument always returns a new token.
Question:
I'm trying to think of Payment Instrument as a payment method, tokenizing a card, and not per payment, but since it returns a different token each time even if I put in the same credit card, am I understanding this wrong? Should I treat the Payment Instrument as something else completely different?
If I were to store a token on our side, which one would I be?
As for payments API, we can pass in a token, does this work for both types mentioned above?
Any help, guidance or thoughts are appreciated
Cybersource is never good at API design or documentation. but their document on this topic could help you understand the concept
https://developer.cybersource.com/api/developer-guides/dita-tms/paymentInstrumentREST.html
Look at the first chart.
A "customer" has a "payment instrument" which associates with a "card", which could have multiple instrument identifiers that each has one-on-one mapping with a specific card number.
This model exists because consumer can have the SAME card updated with different card numbers OR expire date. ("Payment Instrument" tries to represent the "SAMEness" part of it.)
So Cybersource's "Payment Instrument" model can be seen as an "abstract" card object/container representing the working "instrument" (that is why it doesn't store the number) which knows the actual card number that should be used (but the merchant doesn't necessary need to know), in the mean time, it knows the "history" of the card.
The naming is terrible, the "Payment Instrument" itself has an ID, then Instrument Identifier ID is an "ID" too (guess the guy who came up with the name forgot ID is the acronym for "Identifier"? LOL). Very confusing indeed. Just keep in mind that Instrument Identifier ID maps to a card number, "Payment Instrument" ID is a container that maps to a series of (SAME) card numbers (potentially)
So that answers your question why you can get a different "Payment Instrument" ID every time, because you can think of it as different merchant has a different "Payment Instrument" ID for the same customer with that physical card. As long as Cybersource has the record and knows how to find the associated instrument identifier ID via this "Payment Instrument ID", it is mission accomplished.
Again you know Cybersource is a dinosaur living in the past, so you have to deal with it
So my understanding of how this works, is that a payment instrument is a TYPE of payment (ACH, CreditCard, bitcoin, ApplePay™, GooglePay™, etc.) then the instrument identifier is the token (or id) that represents the specific account number within that payment type.
So a payment instrument of Credit Card might have an instrument identifier of Visa account 4242424242424242 but the Token Management Service (TMS) returns an instrument identifier of AA7D990C34583376EB05345443E0234242434B. The TMS allows for relevant information to then be stored within a CUSTOMER identifier (which is the "wallet" owner). As the TMS becomes more feature rich, the addition of things like 'shipping info' and other possible 'preferences' may become available. The other concept is that this digital wallet (TMS token API) can have its permissions granted to other merchant entities so that all payment processing and transactions can be managed through one (OMNICHANEL) API and this payment information can remain SECURE, AUDITABLE, GRANTED, REVOKED, etc.
Now the reason you can get different "tokens" for the same instrument is based on preference. This means that if a cardholder doesn't want to 'keep payment info on file' or 'store the token for later use'. Then the TMS system will provide a token for one-time use, thereby satisfying the requirement of the merchant (reducing PCI scope/risks) and keeping the preference of the cardholder.
This is in no way an official explanation, so I am definitely open to any additional insights on how TMS (from Cybersource™) is designed to work.
-> Generally we create a Return Material Authorization (RMA) against
a Sales Order (SO) when customer rejects the goods.
-> In the above case, if we create a Return Order then the Sales Order
will be referenced here.
-> But Oracle ERP Cost Management module provides us to create a
Return order without referring the sales order also.
-> So generally in what business scenarios do we create that?
When a company sells it's products to distributors, there is an understanding between the Company (seller) and distributor that the distributor would return 5-10% of a product to the seller if it is unsold.
The above said scenario is called Stock Rotation RMA which doesn't have reference Sales Order reference.
For further details on RMA, please read the below link.
https://docs.oracle.com/cd/A60725_05/html/comnls/us/oe/esayrmas.htm
We applied the same that you asked about when we were in going live period, we did all RMA without referencing them to SO because we didn't have a reference SO.
Regards.
Omar Al-Okaidi
I want to create a smart contract and launch it for ICO. I also create a website where people can buy my token. I want know how to check how many token been sold (live)? so i can create a live bar counter to show how many percentages of the token already been sold.
Or is there a way i can monitor the token sale process in the smart contract?
A token contract is no different than any other smart contract. There are no special built in Solidity features or logic associated with them. They are just regular smart contracts that follow a specification.
So, if you want access to the number of tokens sold, you code that into your contract. While tokens sold is not part of the standard ERC20/ERC721 interface, nothing prevents you from adding a constant function to retrieve this information. In fact, if you're using the basic Zeppelin Crowdsale contract, you can just calculate it using the public state variables weiRaised / rate (Chances are you should be creating your own Crowdsale subcontract, so it's better to add the functionality you want there).
We can use the Etherscan Developer API to review transactions against a given contract address and find out the total supply or number of items available for sale.
There is a lot you can do with the Etherscan Developer API. For example, here's one URL that pulls data from Ethereum Mainnet -> Etherscan -> JSON parser -> Shields.io and renders it as an image to calculate the number of Su Squares remaining for sale:
Source: https://img.shields.io/badge/dynamic/json.svg?label=Su+Squares+available&url=https%3A%2F%2Fapi.etherscan.io%2Fapi%3Fmodule%3Daccount%26action%3Dtokenbalance%26contractaddress%3D0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F%26address%3D0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F%26tag%3Dlatest%26apikey%3DYourApiKeyToken&query=%24.result
^ I don't know if SO is going to cache the image here. But that URL is a live URL which pulls the number of Su Squares available hot off the blockchain.
I have a charge code called FREIGHT set up with the following configurations. Under Credit, I've specified a ledger account of 4800.
I now create a Purchase Order, confirm and go through the whole process, and then try to invoice / post it.
I'm presented the following error:
"The combination 4800- is not valid for the account structure MYACCOUNTSTRUCTURE"
So it's been identified that AX is attempting to use 4800 from the aforementioned charges code field MarkupTable.VendorLedgerDimension.
In the code, it crashes in the PurchFormLetter.run() method, and if I did further it goes into the SysOperationController\pack super(); class before it crashes.
Now, if I were to change my account from 4800 to for example 2100, then the invoice goes through fine, which is good.
My question, and what I need is to find out what class / where in the code is this happening during the invoice post process that AX is trying to use this MarkupTable.VendorLedgerDimension field. I need to access that part of the process and modify that value (obviously 4800 is just the display value) to be something else.
If anyone needs more information for background, I need to keep the account for FREIGHT at 4800, while setting the actual financial dimension to the financial dimension on the line item. I've been debugging and looking all over the place for where this process occurs, but have had no luck so far.
If anyone can point me in the right direction, it would be very greatly appreciated.
Thank you.
Check what dimensions are mandatory on this account. Then set financial dimension on invoce lines.
I am creating a Recurring payment profile using Direct payment(credit card details entered during registration are not stored in database). I want to update/change the bill amount for every bill cycle(because billing is done per user per month).
I am using UpdateRecurringPaymentsProfileDetails API method to change the amount, but the method needs credit card details again(for each time it is called). I am getting the credit card details using GetRecurringPaymentsProfileDetails, but this method just returns the last 4 digits of credit card(and does not return CVV2, but this is not major issue here).
Is there any other option to get the full credit card details(at least credit card number) using Paypal APIs or should I have to store credit card numbers in my database? Any help would be highly appreciated.
It's unlikely that you'll be able to get the full credit card number from PayPal; that's why people use PayPal.
Storing credit card information in your database is a huge liability, and should be avoided if at all possible. Once you start storing that information, your company is responsible for keeping that information secure (and that includes developers). Use another third party component if you must, but don't take on such an enormous liability.
I don't know what company you work for, but that's not a decision that a developer should be making on their own. Entire companies have been shut down for mishandling credit card information. The law around that stuff is extremely murky, and even the smallest mistake can result in massive fines.